DEV Community: rising_segun

Mintlify vs. Docusaurus vs. GitBook: Detailed Comparison (2026)

rising_segun — Tue, 18 Aug 2026 00:00:00 +0000

Mintlify, Docusaurus, and GitBook are the three most popular documentation tools for developer documentation. Choosing between these tools comes down to how much control you want, how your team writes and publishes docs, and how much infrastructure you want to manage.

This guide compares the three across setup, writing workflow, customization, API documentation, versioning, search, AI features, analytics, SEO, hosting, maintenance, and pricing.

Mintlify suits developer teams that want a managed docs platform with Git-based workflows and built-in publishing.
Docusaurus gives you the most control, but your team handles deployment and maintenance.
GitBook is a strong fit for teams that want easier collaboration between technical and nontechnical contributors.
API documentation is more nuanced. Mintlify and GitBook offer dedicated features, while Docusaurus usually needs extra tooling.
There is no single winner. Choose based on workflow, control, maintenance, and team structure.

Comparison at a glance

Category	Mintlify	Docusaurus	GitBook
Pricing model	Free Starter; paid Pro and Enterprise plans	Free and open source; you pay for hosting and any third-party services	Free plan; paid site plans start at $65/month
Best for	Developer teams that want managed docs with Git workflows	Engineering teams that want full control and customization	Teams that want managed docs with strong browser-based collaboration
Time to first deploy	Minutes	Depends on setup and hosting	Minutes
Hosting	Managed by Mintlify	You choose and manage hosting	Managed by GitBook
Setup difficulty	Low	Medium to high	Low
Git workflow	Built in	Native Git workflow	GitHub and GitLab sync
Customization	High	Very high	Moderate to high
API docs	Built-in API playground and OpenAPI support	Usually requires plugins or custom tooling	Built-in OpenAPI and interactive API docs
Versioning	Built in	Built in through the versioning CLI	Supported through site variants
Search	Built in	Algolia or other search integrations	Built in
AI features	AI assistant, agent features, MCP	Available through integrations such as Algolia Ask AI	AI search, AI Assistant, MCP, LLM optimizations
Analytics	Built-in insights	Requires third-party analytics	Built-in site insights
Maintenance	Low	Higher	Low

What is Mintlify, Docusaurus, and GitBook?

Mintlify, Docusaurus, and GitBook can all power developer documentation, but they take different approaches to how teams build, publish, and maintain it.

Mintlify: Managed docs for developer teams

Mintlify is a managed documentation platform built around a Git and MDX workflow. Developers can work locally and submit changes through Git, while other contributors can make changes through its web editor. Mintlify handles the documentation site's build, deployment, and hosting.

Best for: Developer-focused teams that want docs-as-code without maintaining the documentation infrastructure.

Pros:

Supports Git-based and browser editing.
Handles hosting and deployment.
Supports OpenAPI-generated API documentation and interactive API features.
Includes built-in search and AI features.

Cons:

Offers less infrastructure control than a self-hosted solution.
Advanced features and larger teams require paid plans.

Docusaurus: Open source with more control

Docusaurus is an open-source static site generator maintained by Meta. Documentation is written in Markdown or MDX and compiled into a static website. Unlike Mintlify and GitBook, Docusaurus does not provide a managed documentation service. Your team chooses the hosting provider and controls the deployment.

Best for: Engineering teams that want more control over their documentation site and are comfortable managing the underlying setup.

Pros:

Free and open source.
Highly customizable with React.
Supports documentation versioning.
Gives you control over hosting and deployment.
Has a large plugin and integration ecosystem.

Cons:

Requires more setup and ongoing maintenance.
Search, analytics, and some documentation features may require third-party services or additional configuration.
Less accessible to nontechnical contributors without a separate editorial workflow.

GitBook: Managed docs for collaborative teams

GitBook is a managed documentation platform that combines browser-based editing with Git workflows. Teams can create and edit documentation in GitBook or use Git Sync to keep content synchronized with GitHub or GitLab. GitBook handles publishing and hosting.

Best for: Teams that want developers and nontechnical contributors to work on the same documentation.

Pros:

Visual editor for browser-based writing.
GitHub and GitLab synchronization.
Managed hosting and publishing.
Built-in search and AI capabilities.
Supports OpenAPI-based API documentation.

Cons:

Less control over the underlying infrastructure than Docusaurus.
Some advanced publishing and collaboration features require paid plans.

Bottom line: Mintlify prioritizes the developer workflow, Docusaurus gives you the most control, and GitBook makes collaborative authoring easier. The rest of this comparison looks at where those differences matter in practice.

Mintlify vs. Docusaurus vs. GitBook: Feature comparison

The biggest differences between these tools show up in how teams build, maintain, and use their documentation. Let's compare the six areas that matter most.

Setup and deployment
Writing and collaboration
Customization
API documentation
Versioning
Search and AI features

Mintlify vs. Docusaurus vs. GitBook pricing

The three tools use different pricing models. Mintlify and GitBook charge for managed platforms, while Docusaurus is free and open source but leaves hosting and maintenance to your team.

Mintlify pricing

Mintlify has three plans:

Starter: Free. Includes five editor seats, Git sync, a custom domain, web editor, search, API playground, authentication, and an MCP server.
Pro: $450 per month billed annually or $540 per month billed monthly. Includes unlimited editor seats and adds preview deployments, Agent, Assistant, Automations, and admin APIs.
Enterprise: Custom pricing. Adds SSO, SCIM, role-based access control (RBAC), advanced insights, a performance SLA, migration support, and enterprise security features.

There is also a usage cost to consider on Pro. Mintlify includes 10,000 credits per month for its AI features and charges $0.01 per credit for overages.

For a small team, the free Starter plan covers much of the core documentation workflow. The price jump comes when you need features such as preview deployments, AI agents, automations, or enterprise controls.

Docusaurus pricing

Docusaurus is free and open source. There are no per-user, per-site, or Docusaurus subscription fees.

The cost comes from running it.

Docusaurus builds your documentation into static files and leaves hosting to you. You can deploy those files to GitHub Pages, Vercel, Netlify, Render, your own server, or another static hosting provider.

Some costs can stay at $0:

GitHub Pages provides free build and deployment for public repositories.
Algolia DocSearch is free for eligible public developer documentation and technical blogs.
Some static hosting providers offer free tiers that may be enough for smaller documentation sites.

But a production setup can introduce costs for hosting, private search, analytics, continuous integration and continuous deployment (CI/CD), monitoring, and other services.

The largest hidden cost is often engineering time. Your team owns the build configuration, dependencies, deployment pipeline, upgrades, integrations, and any custom React components.

GitBook pricing

GitBook charges per published site and per collaborating user:

Free: $0, with one user.
Premium: $65 per site per month when billed annually, plus $12 per user per month.
Ultimate: $249 per site per month when billed annually, plus $12 per user per month.
Enterprise: Custom pricing.

Premium adds features such as custom domains, AI search, analytics, user feedback, redirects, and advanced branding. Ultimate adds GitBook's AI Assistant and other advanced features.

For example, a five-person team running one Premium documentation site would cost:

$65 + (5 × $12) = $125 per month, or $1,500 per year at the published annual-billing rate.

The same five-person team on Ultimate would pay:

$249 + (5 × $12) = $309 per month, or $3,708 per year.

GitBook does not charge based on documentation traffic. Page views are unlimited across its plans.

Total cost of ownership:

The subscription price doesn't tell the whole story.

Cost	Mintlify	Docusaurus	GitBook
Platform	$0; Pro from $450/month when billed annually	$0	$0; Premium from $65/month when billed annually
Additional users	Included by plan	$0 platform fee	$12/user/month on paid plans
Hosting	Included	You provide it	Included
Search	Included	Separate; can be free	Included
Deployment	Managed	You manage it	Managed
Maintenance	Mostly managed	Your team	Mostly managed
AI usage costs	Credits and possible overages	Depends on tooling	Included features vary by plan

Bottom line: Compare the subscription price with the engineering time your team will spend running the documentation stack. For Docusaurus in particular, "$0" describes the software license, not necessarily the cost of ownership.

When should you choose Mintlify?

Choose Mintlify if you want a developer-focused documentation platform without owning the infrastructure.

Mintlify is a good fit if:

Your developers already work in Git. Documentation can live in the repository and follow the same branch, pull request, and review workflow as code.
You want managed docs without giving up docs-as-code. Mintlify handles hosting and deployment while your team works with MDX and Git.
API documentation is a core part of your docs. Mintlify supports OpenAPI-generated references and an interactive API playground.
You want AI features built into the documentation platform. Mintlify provides AI search and assistant features, llms.txt, MCP support, and tools for making documentation available to AI agents.
You don't want engineers maintaining the docs stack. You give up some infrastructure control, but you also avoid managing builds, hosting, search, and much of the deployment pipeline.

Skip Mintlify if: You need full control over the frontend or want to self-host the entire documentation stack.

Best fit: Developer tools, APIs, SDKs, and technical products with engineering-led documentation.

When should you choose Docusaurus?

Choose Docusaurus if control matters more than convenience.

Docusaurus is a good fit if:

Your team is comfortable with React. You can build custom components, layouts, themes, and documentation experiences instead of staying within a managed platform's boundaries.
You want to control hosting and deployment. Docusaurus generates static files that you can deploy through your existing infrastructure.
Your docs need heavy customization. This is useful when documentation needs to share components, branding, or functionality with the rest of your developer experience.
You already have engineering resources for the docs stack. Maintaining dependencies, CI/CD, hosting, search, plugins, and upgrades is less of a problem when someone owns them.
You want an open-source foundation. Docusaurus itself has no platform subscription or per-user fee.

Skip Docusaurus if: You want a documentation platform your team can publish and maintain with little engineering involvement.

Best fit: Engineering-led teams that value customization, infrastructure ownership, and extensibility over a managed experience.

When should you choose GitBook?

Choose GitBook if documentation is shared across engineering, product, support, and other teams.

GitBook is a good fit if:

Not everyone writing documentation uses Git. Contributors can work in GitBook's visual editor without managing repositories or local development environments.
Developers still need a Git workflow. Git Sync connects documentation with GitHub or GitLab, so technical contributors don't have to abandon their existing workflow.
Collaboration matters more than frontend control. GitBook handles publishing and hosting while giving teams tools for editing, reviewing, and managing content.
You need public and private documentation. GitBook supports published documentation as well as authenticated access for restricted content.
You want API docs without building the tooling yourself. GitBook can generate interactive API documentation from OpenAPI specifications.

Skip GitBook if: Deep frontend customization or complete infrastructure ownership is a requirement.

Best fit: Cross-functional teams that need developers and nontechnical contributors to maintain documentation together.

Here is a quick decision. If you're still deciding, reduce it to one question:

Want a managed platform built around developer workflows? Choose Mintlify.
Want maximum control and don't mind maintaining the stack? Choose Docusaurus.
Want developers and nontechnical teams contributing together? Choose GitBook.

Final Take

Mintlify offers a managed, developer-focused workflow, Docusaurus gives engineering teams more control, and GitBook makes it easier for technical and nontechnical teams to work on documentation together. The right choice depends on how your team works and how much of the documentation stack you want to manage.

Need help with your developer documentation?

Choosing the right platform is only part of the job. Reclear helps developer-first teams plan, build, and improve documentation for APIs, SDKs, and technical products across Mintlify, Docusaurus, GitBook, and other documentation stacks.

We also offer a free documentation audit to identify gaps in your structure, content, developer experience, and tooling.

Book a call with Reclear

10 Best PaaS Providers for Web Apps in 2026

rising_segun — Sat, 18 Jul 2026 00:00:00 +0000

Platform-as-a-service (PaaS) lets you deploy a web app without provisioning servers, patching OSes, or wiring CI/CD from scratch. You push code (usually from GitHub or GitLab) and the platform handles builds, SSL, routing, and scaling.

That is different from static hosting. A real web app needs a process that stays up, talks to a database, runs background jobs, and often keeps WebSockets or long-lived connections open. The best PaaS for that job is not always the same one that wins for a marketing site or a Next.js frontend.

This guide ranks 10 PaaS providers for web apps in 2026 , with seenode first: predictable fixed pricing, always-on services, managed databases, and a deploy-from-Git workflow that still feels like classic Heroku, without the surprise invoices.

Pricing and features below are based on publicly available docs as of July 2026 and can change by region and plan.

Key takeaways

Pick always-on PaaS (seenode, Railway, Render, Fly.io, Heroku) when you need persistent processes, WebSockets, or workers, not only serverless functions.
Pick frontend / edge PaaS (Vercel, Netlify, Cloudflare Pages) when the app is mostly static or serverless and you want global CDN performance.
Billing model matters as much as features. Fixed tiers (seenode, Render) beat usage metering if you hate surprise bills; usage-based (Railway, Fly.io) can win for bursty traffic.
For a full stack under ~$15/month with a database, seenode is usually the cheapest always-on option in this list.
Hyperscaler-adjacent tools (DigitalOcean App Platform, AWS Amplify) shine when you already live in that ecosystem.

Quick comparison

Provider	Best for	Pricing from*	Billing	Always-on	Managed DB
seenode	Predictable cost full-stack apps	From $3/mo	Fixed tiers	Yes	Postgres, MySQL
Railway	Heroku-like DX, variable traffic	Free trial / usage	Usage-based	Yes	Yes
Render	Production defaults, teams	Free tier / paid	Fixed + usage	Yes	Postgres, Redis
Vercel	Next.js and frontend apps	Free / Pro ~$20/mo	Seat + usage	Serverless	Via partners
DigitalOcean App Platform	Hybrid PaaS + DO cloud	Free / ~$5/mo	Fixed	Yes	Yes
Fly.io	Multi-region, low latency	Usage-based	Usage-based	Yes	Optional managed
Heroku	Mature classic PaaS	~$7/mo dynos	Dyno tiers	Yes	Postgres + add-ons
Netlify	JAMstack / Deploy Previews	Free / ~$9-20/mo	Seat + usage	Serverless	Via partners
AWS Amplify	AWS-centric full-stack frontends	Free tier / usage	Usage-based	Mixed	Via AWS
Cloudflare Pages	Edge speed, static + Workers	Free / paid	Usage-based	Edge	Via partners

*Entry prices are approximate starting points for a small app; real stacks (web + DB + seats) usually cost more. See each section.

How we evaluated

We scored platforms the way a small team actually chooses:

Stack fit: Can you run Python, Node.js, Go, or similar backends, not only static sites?
Developer experience: Git deploys, logs, previews, dashboards without a dedicated DevOps person.
Pricing predictability: Fixed tiers vs metered CPU/egress vs per-seat plans.
Databases & workers: Managed Postgres/MySQL, background workers, private networking.
Runtime model: Always-on processes vs serverless/edge (cold starts, WebSockets, timeouts).
Support: Docs quality and whether a human will help when a deploy breaks at 6pm.

For a deeper look at billing models specifically, see our Heroku alternatives decision framework.

1. seenode: best for predictable, always-on web apps

seenode is a developer PaaS built for shipping web services, workers, and managed databases without becoming an infrastructure team. Connect GitHub or GitLab, pick a repo, and get a public URL with SSL. You can even start a deploy before creating an account, claim it when you are ready, with a 7-day free trial.

seenode targets the gap left after Heroku’s free tier disappeared: always-on apps with Heroku-like simplicity and fixed monthly pricing. No cold starts, no per-request metering, no per-seat fees. That makes it a strong default for side projects, MVPs, and small SaaS products that need a real backend plus Postgres or MySQL.

Native runtimes include Python, Node.js, Go, and Elixir. You get centralized logs (7 days), private networking between services, zero-downtime deploys, horizontal or vertical scaling, and unlimited team members. Support is live chat with platform engineers, not a ticket black hole.

seenode key features

Git-based deploys from GitHub/GitLab with automatic builds and SSL URLs
Zero cold starts: always-on processes for WebSockets, SSE, and persistent connections
Managed PostgreSQL and MySQL in the same project as your apps and workers
Fixed monthly pricing , charged daily, with no per-seat or per-request surprises
Unlimited team seats and pair-debugging support from the people who build the platform

seenode pricing (as of July 2026)

Pricing starts at $3/month for a basic web service. A common starter stack with web + Postgres is often around $7 to $11/month , depending on tier. Larger setups stay fixed-tier; seenode’s public comparison shows a 3-app + Postgres + storage stack at roughly $15.50/month vs much higher on Render for a similar footprint. Explore current numbers on seenode pricing.

Best for: Solo developers and small teams who want always-on apps, a database, and a bill they can predict.

Skip if: You need multi-region edge by default or a huge add-on marketplace on day one.

seenode

Deploy your app on seenode

Connect GitHub, pick a repo, and go live in minutes. No account or credit card required to start. 7-day free trial.
See pricing

Deploy from GitHub

2. Railway: best for Heroku-like workflows with usage billing

Railway is the platform many teams tried first after leaving Heroku. Deploy from Git, Docker, or the CLI; attach managed databases; use private networking between services. The DX is fast, and the product feels built for full-stack apps rather than marketing sites.

The tradeoff is usage-based pricing. Quiet apps can stay cheap; sustained traffic or chatty services can push the bill up quickly. That is fine if you watch usage, painful if you do not.

Railway key features

Git, Docker, and local deploy paths with rollbacks and observability
Managed databases and persistent volumes
Private networking and TCP proxies
Unlimited preview environments on higher plans
Usage-based Hobby and Pro tiers

Railway pricing

Hobby includes a small usage credit; Pro is commonly around $20/month with included credit, and real production apps often land in the $20-30+/month range depending on CPU, memory, and egress.

Best for: Variable traffic and teams that like Railway’s project model.

Skip if: You need a fixed invoice every month.

3. Render: best for production-ready defaults

Render is a unified cloud for web services, static sites, background workers, cron jobs, and managed Postgres/Redis. Git auto-deploys, zero-downtime releases, and private networking make it a common “boring production” choice for agencies and startups.

Pricing is more expensive than seenode for comparable always-on stacks, especially once you add Postgres with production features and a paid workspace. You pay for stability and a mature feature set.

Render key features

Automatic Git deploys and Docker support
Native workers, cron jobs, and preview environments
Managed PostgreSQL and Redis with private networking
Infrastructure as Code via render.yaml
DDoS protection and zero-downtime deploys

Render pricing

Free tiers exist for experiments; production web + Postgres setups often start in the tens of dollars per month and climb with PITR, larger DBs, and team plans.

Best for: Client work and teams that want opinionated production defaults.

Skip if: Budget is under ~$15/month for web + database.

4. Vercel: best for Next.js and frontend-centric apps

Vercel owns the Next.js deployment experience: Git integration, preview deployments per PR, and a global edge network. Serverless and edge functions cover APIs, but the platform is optimized for frontend and JAMstack patterns, not long-running backends.

If your “web app” is mostly React/Next with serverless APIs, Vercel is excellent. If you need always-on workers, WebSockets, or a traditional app server, look at seenode, Railway, Render, or Fly.io instead.

Vercel key features

First-class Next.js and modern frontend frameworks
Preview deployments and team collaboration controls
Edge network, serverless functions, and AI SDK tooling
Integrated storage options (Blob and related services)

Vercel pricing

Generous free hobby tier; Pro from about $20/month per seat, plus usage for functions and bandwidth on heavier apps.

Best for: Next.js products and frontend teams.

Skip if: You need persistent servers, workers, or cheap always-on Postgres next to the app.

5. DigitalOcean App Platform: best for hybrid PaaS + cloud

DigitalOcean App Platform sits on top of DigitalOcean’s broader cloud: deploy from Git or containers, mix services/workers/static sites, and grow into Droplets, managed databases, or GPU/AI products when you need them.

It is a solid middle ground when you want PaaS simplicity with an escape hatch into classic cloud infrastructure, without jumping straight to AWS complexity.

DigitalOcean App Platform key features

Git-based deploys with component architecture (services, workers, static sites)
Built-in HTTPS, CDN, and app-level logs
Vertical and component-level scaling
Path into Droplets, managed DBs, and AI/GPU products

DigitalOcean pricing

Static/free tiers for light apps; paid App Platform plans commonly start around $5/month , with costs rising as you add dedicated CPU and databases.

Best for: Teams that want managed deploys plus optional DO infrastructure.

Skip if: You only need a tiny always-on API and want the absolute lowest fixed bill.

6. Fly.io: best for multi-region and proximity to users

Fly.io runs full containers close to users across many regions. That is powerful for latency-sensitive apps and global products. Machines can scale to zero, which helps cost, but managed Postgres and always-on capacity change the economics fast.

Expect a steeper learning curve than seenode or Railway. The payoff is control over where your app runs.

Fly.io key features

Global regions and Anycast networking
Full Docker/OCI workloads with scaling options
Optional managed Postgres (watch the price jump)
Strong fit for latency-sensitive APIs

Fly.io pricing

Usage-based compute can look cheap for idle hobby apps ( often under $15/month without managed Postgres). Adding managed Postgres frequently pushes totals toward ~$45-50/month , a cliff many comparison posts underplay.

Best for: Multi-region and performance-sensitive workloads.

Skip if: You want the simplest dashboard and a flat invoice.

7. Heroku: best for mature, classic PaaS

Heroku invented the dyno mental model many of us still use. Buildpacks, add-ons, review apps, and a huge ecosystem remain useful. The platform is stable and familiar, but innovation is slower, and pricing is rarely the cheapest option for a small always-on stack.

Still a valid choice if your team already knows Heroku or depends on specific add-ons.

Heroku key features

Dyno-based scaling and Cloud Native Buildpacks
Large add-on marketplace (data, monitoring, messaging)
Private Spaces and compliance-oriented offerings
Mature CLI and developer workflow

Heroku pricing

Basic dynos often start around $7/month , with Postgres and add-ons stacking quickly for production.

Best for: Teams standardized on Heroku’s ecosystem.

Skip if: You are cost-sensitive or want the newest PaaS DX.

8. Netlify: best for JAMstack and Deploy Previews

Netlify popularized Deploy Previews and a polished JAMstack workflow. Global CDN, serverless/edge functions, forms, and identity features make it strong for content sites and frontend apps, not a replacement for a classic always-on API host.

Netlify key features

Deploy Previews tied to pull requests
Serverless and edge functions
Global CDN and build tooling
Identity and forms on higher plans

Netlify pricing

Free personal tier; paid plans commonly from about $9-20/user/month plus usage.

Best for: Marketing sites, docs, and frontend-heavy products.

Skip if: Your core product is a long-running backend.

9. AWS Amplify: best for AWS-centric frontends

AWS Amplify helps frontend teams deploy apps and wire into Cognito, AppSync, S3, and the rest of AWS. Pull request previews and Amplify Hosting are convenient if you already live in Amazon’s ecosystem.

The downside is classic AWS: powerful, but complexity and cost visibility can grow quickly once you leave the happy path.

AWS Amplify key features

Hosting with PR previews
Auth, storage, and API integrations with AWS services
Amplify Studio and CLI for backend wiring
Fits teams already standardized on AWS

AWS Amplify pricing

Pay for Amplify Hosting and underlying AWS resources. Entry can look cheap; production AWS bills need monitoring.

Best for: Frontend apps that must plug into AWS deeply.

Skip if: You want a simple Heroku-style PaaS with one predictable invoice.

10. Cloudflare Pages: best for edge speed and static-first apps

Cloudflare Pages deploys sites and JAMstack apps onto Cloudflare’s global network, with Pages Functions (Workers) for dynamic behavior at the edge. Unlimited bandwidth on Pages plans is a real advantage for traffic spikes.

Like Vercel and Netlify, it is not the first pick for traditional always-on app servers, but for edge-first architectures it is hard to beat on latency and CDN reach.

Cloudflare Pages key features

Git-integrated continuous deployment
Pages Functions on the edge network
Global CDN performance and DDoS posture
Unmetered bandwidth on Pages plans

Cloudflare pricing

Generous free tier; paid Workers/Pages plans for heavier compute and team features.

Best for: Static and edge-rendered apps that need global speed.

Skip if: You need a classic always-on Node/Python process next to managed Postgres in one dashboard.

How to choose the right PaaS

Use this shortcut:

Side project or MVP under $15/month with a database → seenode
Heroku-like DX and you accept usage bills → Railway
Agency / client production defaults → Render
Next.js-first product → Vercel (pair a backend PaaS if you outgrow serverless)
Already on DigitalOcean → App Platform
Need many regions → Fly.io
Frontend/edge only → Netlify or Cloudflare Pages
Deep AWS integration → Amplify

If billing model is the deciding factor, read the full breakdown in Heroku Alternatives Decision Framework.

seenode

Still deciding? Deploy a real repo

Compare seenode to Railway or Render with the same app. No credit card required to start. 7-day free trial.
See pricing

Deploy from GitHub

FAQ

What is the best PaaS for a large-scale web app?

For large scale, prioritize autoscaling, observability, and operational maturity. Render , Fly.io , and hyperscaler-adjacent platforms (DigitalOcean, AWS) are common choices. Many teams still start on a simpler always-on PaaS like seenode or Railway , then split services or move parts of the stack when traffic justifies it. Pure VPS/IaaS wins only when you need OS-level control that PaaS will not give you.

Is PaaS better than VPS hosting for web apps?

For most product teams, yes. PaaS is faster to ship and cheaper in engineering time. Choose a VPS when you need custom kernels, unusual networking, or specialized software that no PaaS supports. Do not pick a VPS just to “save money” unless you enjoy being on-call for patching and SSL renewals.

Which PaaS is best if I am leaving Heroku?

Closest workflow: Railway. Closest economics for a small always-on app + database: seenode. Closest “enterprise boring”: Render. Details and cost tables: Heroku alternatives decision framework.

Can I host a full-stack app with a database on these platforms?

Yes on seenode , Railway , Render , DigitalOcean , Fly.io , and Heroku. On Vercel , Netlify , Amplify , and Cloudflare Pages , you typically attach an external database (Neon, PlanetScale, Supabase, RDS, etc.) and keep the host focused on frontend/serverless.

How do I migrate to seenode?

Point a GitHub or GitLab repo at seenode, set build/start commands and env vars, provision Postgres or MySQL if needed, and deploy. Start from the seenode docs or just deploy from GitHub.

Ship your web app without the infrastructure tax

If you want always-on web services, workers, and managed databases with fixed pricing and no per-seat fees , seenode is built for that: predictable invoices, no per-seat fees, and a deploy loop that gets out of your way.

seenode

Ship your web app on seenode

Deploy from GitHub in minutes. Claim the account when you are ready. Keep the invoice predictable as you grow.
See pricing

Deploy from GitHub

How to Try Egonex ECP in .NET 8 and Send Emergency Alerts with an 8-Byte Payload

rising_segun — Wed, 15 Apr 2026 22:52:39 +0000

Disclosure: I was asked by the ECP team to evaluate their SDK and write an honest review. All opinions are my own.

Emergency alerts are usually discussed in terms of speed, reach, and reliability. But there is another variable underneath all of that that matters just as much in practice: how much data the system has to move to describe the alert in the first place.

That is part of what makes ECP, short for Emergency Communication Protocol, interesting. In the default ProofCard run, the sample produces 669 bytes in CAP XML, 270 bytes in JSON, and just 8 bytes in ECP’s UET format. When modified to the earthquake scenario used in this walkthrough, the output becomes 686 bytes in CAP XML, 279 bytes in JSON, and still 8 bytes in ECP UET. The project also reports an average 96 percent data reduction. Those numbers are striking enough that they deserve more than a quick skim of a README.

They are also interesting for reasons beyond a neat benchmark. In emergency systems, smaller payloads can matter when alerts need to move across constrained or failure-prone links, and many public-warning delivery channels still impose practical size or formatting constraints on what can be transmitted. For low-bandwidth deployments or any workflow where overhead matters, the difference between a few hundred bytes and a single-digit payload is not just cosmetic. It can shape how efficiently a message is encoded, transmitted, retried, and inspected.

This article walks through the practical side of that claim using the open-source .NET 8 SDK. The goal is simple: clone the repository, get the environment working, run the tests, execute the samples, modify one of them, generate a real payload, and then verify the result in ECP Studio. By the end, the point is not just to repeat that ECP is compact, but to see what the workflow actually looks like when the SDK is run locally and the output is validated step by step.

Getting set up

The setup path is straightforward on paper. The repository can be cloned, restored, and tested through the normal .NET CLI flow, which makes this feel familiar if you have worked through a standard .NET repository before.

git clone https://github.com/Egonex-Code/ecp-protocol.git
cd ecp-protocol
dotnet restore
dotnet test

There was, however, one environment issue worth mentioning because it is the kind of thing that can derail a hands-on review early. In the local run, dotnet test initially failed with a missing Microsoft.NETCore.App 8.0.6 message because the machine only had .NET 10 installed while the solution targeted net8.0. Installing the .NET 8 SDK resolved the version gap, but the shell was still resolving dotnet to an older local install under .dotnet, so the PATH had to be corrected before the CLI started returning an 8.0.4xx build.

Once the environment pointed at the right SDK, the rest of the process snapped into place. The repository restored successfully, and the full test run passed across the solution, which is exactly the kind of baseline confirmation worth getting before drawing any conclusions about the SDK itself. That also helped separate an environment problem from a repo problem, which is always useful when writing about a developer workflow.

Since this run, the repository added a global.json pin with rollForward: latestFeature (released in v2.0.6), so new clones should not run into the same SDK resolution issue.

Figure: Full dotnet test run on net8.0 passing across the ECP solution.

Running the samples

The best place to start after setup is the ProofCard sample because it makes the central claim visible almost immediately. In the default run, the sample output shows CAP XML at 669 bytes, JSON at 270 bytes, and ECP UET at 8 bytes. In the modified earthquake run from this walkthrough, the output is CAP XML at 686 bytes, JSON at 279 bytes, and ECP UET still at 8 bytes.

That is the moment where the protocol starts to feel concrete. It is one thing to read that a format is compact; it is another to run a sample and see the same alert represented across multiple encodings with the byte counts sitting side by side in the console. The ProofCard sample works well because it does not bury the value proposition in pages of explanation. It just shows the numbers and lets them do most of the work.

Figure: ProofCard size comparison output showing CAP XML vs JSON vs ECP UET.

Figure: Byte comparison chart for the Fire scenario (CAP XML 669, JSON 270, ECP UET 8).

To make the exercise more than a copy-and-run test, the next step was to change the scenario. The local notes modified the sample from a fire scenario to an earthquake scenario, updated the zone hash to 2002, and switched the alert call to EmergencyType.Earthquake. That change produced output identifying the scenario as EARTHQUAKE / Zone 12, along with a new proof hash and a generated payload, which made the sample feel like an actual SDK surface rather than a fixed demo.

A simplified version of the alert call looked like this:

var alert = Ecp.Alert(
    EmergencyType.Earthquake,
    zoneHash: 2002,
    priority: EcpPriority.Critical,
    timestampMinutes: 12345
);

This is one of the more encouraging parts of the SDK experience. At the level tested here, the API surface for a basic alert does not feel huge, and the changes needed to move from the default scenario to a custom one are small enough to follow without getting lost in abstraction.

Another sample worth checking is the signed-envelope round-trip flow. In the local walkthrough, that sample generated an HMAC key, encoded an envelope, and then attempted validation with both the correct key and the wrong one. The wrong-key path returned IsValid False, which is a compact but effective demonstration of validation and tamper detection behavior.

Figure: ECP.Sample.Minimal plus 02-EnvelopeSignedRoundtrip, including wrong-key verification failure (IsValid: False).

Figure: Signed-envelope decode flow showing valid-key success and wrong-key failure.

Verifying in Studio

The most satisfying part of the process came after generating a real payload locally. Running the modified sample with payload output enabled produced the UET hex value 2C001F48C0E40000, which then became the input for the browser-side verification step.

Pasting that value into ECP Studio’s Decode tab parsed it back into the same fields used in the sample, including EmergencyType: Earthquake, Priority: Critical, ZoneHash: 2002, and TimestampMinutes: 12345. That round-trip is what ties the whole workflow together. The code generates the bytes, the browser tool decodes them, and the fields line up without needing an extra helper script or custom parser.

Figure: dotnet run -- --show-payload output, including CAP, JSON, and UET hex (2C001F48C0E40000).

Figure: ECP Studio Decode tab parsing 2C001F48C0E40000 into Earthquake/Critical/ZoneHash 2002/TimestampMinutes 12345.

Studio also helps with the part of the protocol that is harder to communicate through prose alone: comparison. The local notes mention using the Compare tab to make the size differences easier to grasp visually as scenarios change, which gives the browser tool a real role beyond simple decoding. It becomes a practical companion to the SDK rather than just a nice extra.

This is also where the broader implication of the compact payload starts to click. If a machine-readable emergency alert can be represented in 8 bytes for its core form while equivalent CAP XML and JSON representations are measured in the hundreds of bytes in the same sample, that can matter in emergency systems, low-bandwidth environments, and any workflow where message overhead competes with transport constraints or reliability goals. Even when the surrounding system still needs richer metadata, logs, signatures, or interoperability layers, reducing the size of the core alert token can change the shape of the transmission problem.

What stands out

What stands out most after running through the SDK is not that the repository is unusually complex. It is that the path from install to validation is fairly short once the machine is pointing at the correct .NET 8 environment. The repository tests provide a clear baseline, the ProofCard sample shows the size difference immediately, the scenario changes are easy to follow, and Studio closes the loop by decoding the locally generated payload back into readable fields.

That is what makes the 8-byte claim more interesting than a headline. In this case, it was not just a number in project copy or a benchmark repeated from a README; it was something that could be reproduced locally, inspected in the console, modified through a small code change, and verified through the project’s own browser tooling.

For developers working near emergency communications, constrained networks, or systems where payload size affects efficiency, the practical takeaway is straightforward. ECP becomes much easier to evaluate once it moves from an abstract compression claim to a concrete engineering workflow: clone the repo, run the SDK, generate the alert, and verify the bytes yourself. And that is really the point of a hands-on review like this one: not just to admire the 8-byte number, but to test whether the path from idea to validation is real. Developers who want to work with the encoder and decoder directly can start with the ECP.Core package on NuGet.

Resources

GitHub repository: Egonex-Code/ecp-protocol
NuGet package: ECP.Core
ECP Studio: egonex-code.github.io/ecp-protocol/studio/
Wire format specification: docs/specification/wire-format.md

Why Your Developer Tutorials Aren't Converting and How to Fix Them

rising_segun — Sun, 15 Mar 2026 00:00:00 +0000

TL;DR

Developer tutorials fail to convert because they delay the first working result and focus too much on explanation instead of execution
Conversion in devtools happens when a developer gets something working, not when they understand the product
High-converting tutorials optimize for Time to First Success (TTFS) with clear outcomes, minimal setup, and runnable examples
The best tutorials guide developers to a quick win, reduce friction, and are continuously improved based on real usage

A developer comes to your tutorial with a specific goal in mind. They want to try your product and get something working quickly. A few steps in, they are still setting things up, reading through explanations, and trying to make sense of everything. There is no clear result yet, no small win to confirm they are on the right path. After a while, they give up and leave. This is where most tutorials fail. Not because they are wrong, but because they do not lead to a quick win.

This article breaks down why developer tutorials do not convert and how to fix them. It explores where most tutorials go wrong, what high-converting tutorials do differently, and how to design tutorials that guide developers from first interaction to real success.

Developer tutorials are your real conversion funnel

In devtools, conversion does not happen at signup. It happens when a developer gets something working.

A developer can create an account, read your docs, and still leave without ever using your product. What changes that is a working result. The moment they make a successful API call, see data returned, or complete a small task, that is when your product starts to make sense.

This is why tutorials matter more than most teams think. Documentation helps developers understand your product, but tutorials are what help them experience it. They are the bridge between interest and actual usage.

You can think of it simply. Documentation supports onboarding. Tutorials create the first success. That first success drives adoption.

If your tutorial does not get a developer to a working outcome quickly, your product never gets a fair chance.

Where most developer tutorials break down

Most developer tutorials look complete, but they fail where it matters. They do not help developers get to a working outcome fast enough. The result is content that seems useful but does not move the developer forward in the moment it counts.

Here are the most common points where developer tutorials break down:

No clear outcome

Many tutorials start with vague goals like “build something” or “get started.” The problem is that the developer does not know what success looks like.

Compare this:

Build a sample app vs
Create a working API request that returns user data

The second gives a clear destination. The first leaves the developer guessing.

A good tutorial defines the exact outcome upfront. If a developer cannot picture what they will achieve, they are less likely to stay.

Time to first success is too long

This is one of the biggest reasons tutorials fail.

Before a developer sees any result, they are asked to:

install multiple dependencies
configure environments
understand several concepts at once

By the time they reach anything meaningful, they are already fatigued.

This is where the idea of Time to First Success (TTFS) becomes important.

TTFS is how long it takes for a developer to get something working for the first time. The longer it takes to reach that first working result, the more likely the developer is to drop off. High-converting tutorials reduce this time aggressively.

Tutorials explain instead of execute

Some tutorials read like documentation pages. They explain how the system works in detail, but delay actual execution.

Developers are not looking for a deep explanation at the start. They want to take action.

When tutorials lead with long explanations instead of a working step, they slow down progress. Explanation should support action, not replace it.

Examples don’t actually work

Nothing breaks trust faster than a tutorial that does not produce the expected result.

Common issues include:

missing steps or assumptions
outdated versions or dependencies
unclear configuration requirements

If a developer follows your tutorial and it does not work, they will assume the product is unreliable.

This is where strong documentation practices matter. Examples should be complete, runnable, and validated, just like in high-quality developer documentation that gets used. The same principle applies even more strongly to tutorials.

Not tied to a real use case

Some tutorials are technically correct but feel disconnected from real-world problems.

They demonstrate features in isolation without answering a practical question like:

why would I use this
when would I need this

Developers want to solve real problems. Tutorials that are not grounded in actual use cases feel disconnected from real-world problems and are easier to abandon.

Most developer tutorials fail not because they are wrong, but because they do not help developers move forward fast enough.

The aha moment: developers don’t convert when they understand, they convert when they succeed

It is easy to assume that developers convert when they understand your product. That's if your tutorial explains things clearly enough, they will see the value and continue.

In reality, understanding is not what drives adoption. Execution is.

A developer can read your documentation, follow your architecture, and still leave without using your product. But the moment they get something working, even something small, the experience changes. The product stops being abstract and starts becoming useful.

This is the shift most teams miss.

A developer who understands your product might still leave. A developer who gets something working will come back.

This is why tutorials matter so much. They are not just educational content. They are the first real interaction a developer has with your product.

If that interaction leads to success, you build confidence. If it leads to friction, you lose momentum.

Everything about your tutorial should be designed around this idea. Not how much you can explain, but how quickly you can help a developer succeed.

How to fix your developer tutorials (practical system)

Once you understand where developer tutorials fail and what actually drives conversion, the next step is fixing them. This is not about rewriting everything. It is about restructuring your tutorials around how developers make progress.

Start by being explicit about what the developer will achieve.

Avoid vague goals like:

“Build a sample app”
“Get started with the API”

Instead, define a clear, concrete result:

“Create a user via the API and return a successful response”
“Upload a file and retrieve its URL”
“Authenticate a user and receive a valid token”

A strong developer tutorial answers this immediately: What will I have working at the end of this?

You can make this even clearer by showing the expected output upfront.

{
  "id": "user_123",
  "email": "user@example.com"
}

Most developer tutorials lose users before they even begin.

Too many tutorials start with:

environment setup
dependency installation
configuration steps

Before any value is shown.

Every extra step before the first success increases drop-off. Your goal is to reduce setup to only what is absolutely required. Instead of:

installing multiple tools
configuring environments manually

You should consider:

providing a pre-configured example
using simple tools like curl or a single SDK
deferring advanced setup to later sections

For example, instead of asking a developer to install a full SDK, start with:

curl -X GET https://api.example.com/v1/users \
  -H "Authorization: Bearer YOUR_API_KEY"

This gets them to a working result faster. That is what matters.

Before writing explanations, make sure the tutorial works end-to-end.

This means:

every step is tested
every command runs
every response is valid

Do not write the tutorial as you build the product. Write it after you have a working flow.

A simple rule: If you copy your own tutorial and it fails, the tutorial is not ready.

For example, instead of:

POST /v1/users

You should write the full, runnable version:

curl -X POST https://api.example.com/v1/users \
  -H "Authorization: Bearer sk_test_123456" \
  -H "Content-Type: application/json" \
  -d '{
    "email": "user@example.com"
  }'

This reduces guesswork and builds trust immediately.

Once the working example is clear, add explanation that helps the developer move forward.

Focus on:

what each step is doing
what can be changed
what to expect next

Avoid long sections that explain the system before the developer has seen it work.

For example, instead of starting with: “Our authentication system uses token-based access with…”

You can start with:

-H "Authorization: Bearer YOUR_API_KEY"

Then explain: This header authenticates your request. Replace YOUR_API_KEY with your actual key.

Ideally, your explanation should support execution, not delay it.

This is where most teams underestimate the problem.

You need to measure how long it takes for a developer to get a working result.

Ask:

How many steps before the first success
How long does it take to complete
Where do developers get stuck

If it takes 15–20 minutes to get a result, your tutorial is already at risk.

High-converting developer tutorials aim for a working outcome within minutes, not tens of minutes

You can validate this by running the tutorial from scratch, asking someone unfamiliar to try it, and observing where they hesitate or drop off

Even after publishing, your tutorial is not finished.

Watch for:

repeated developer questions
support tickets
points where users drop off

These are signals of friction. Then iterate:

simplify steps
remove unnecessary complexity
clarify instructions

For example, If multiple developers struggle with authentication, your tutorial should be updated to make that step clearer or earlier.

This is the difference between tutorials that exist and tutorials that convert.

Fixing developer tutorials is not about adding more content. It is about making it easier for developers to succeed.

When your tutorials are built around clear outcomes, minimal setup, working examples, and fast results, they stop being just documentation. They become a reliable path to product adoption.

This is what separates tutorials that get read from tutorials that convert.

Developer tutorials that actually convert

Some devtools get this right. Not because they write more, but because they design tutorials around quick success.

If you look closely, the pattern is consistent. The best tutorials are not trying to explain everything. They are designed to get something working as fast as possible.

Stripe: immediate API success

Stripe’s tutorials are built around one simple idea. Make a working API request as quickly as possible.

You are not asked to understand the entire system first. You are given a clear task, a ready-to-use request, and an expected response.

Within minutes, you can:

send a request
receive a response
confirm that everything works

That first success builds confidence. From there, developers are more willing to explore deeper parts of the product.

Supabase: build something real, fast

Supabase tutorials focus on building something tangible early.

Instead of abstract examples, you are guided to:

create a project
connect to a database
fetch or insert data

You are not left guessing what the end result should be. You see it happen.

This makes the tutorial feel useful immediately. It is not just showing features, it is helping you achieve something that resembles a real use case.

Vercel: deploy and see it live

Vercel tutorials reduce friction to the point where deployment feels instant.

You go from:

connecting a repository to
having a live URL

In just a few steps.

There is almost no delay between action and result. That speed is what makes the experience memorable.

The tutorial does not try to teach everything about deployment. It focuses on getting something live first. Everything else can come later.

Across these examples, the same principles show up:

you get a working result quickly
the steps are clear and minimal
the outcome is visible and verifiable
the tutorial is tied to something real

This is what high-converting developer tutorials look like.

They are not longer. They are not more detailed. They are simply better designed around how developers experience progress.

Conclusion

Developer tutorials are not just content. They are where adoption happens. When a tutorial leads to a quick, working result, it builds confidence and keeps developers moving forward.

The difference is not in how much you explain, but how quickly you help a developer succeed.

At Reclear, we help teams design and write developer tutorials and documentation that drive real product adoption. If you are looking to improve your tutorials or build them from scratch, you can reach out to see how we can help.

Work with us: Book a call to discuss how we can help with your developer documentation and technical content.

Heroku Alternatives Decision Framework: What Actually Matters When Picking a PaaS

rising_segun — Fri, 30 Jan 2026 10:43:00 +0000

TL;DR: After Heroku killed their free tier, everyone rushed to Railway, Render, and Fly. Three years later, here is the framework that actually matters for picking between them based on billing model, not feature lists.

When Heroku discontinued their free tier in November 2022, hundreds of thousands of projects had to migrate. Most comparison posts you will find today are just feature lists. This guide focuses on what matters in practice after using all of these platforms in production: how they bill you and how that interacts with your traffic pattern and your tolerance for surprise invoices.

Quick Decision Helper

Need predictable costs? → Fixed tiers (Seenode, Render)
Traffic varies wildly? → Usage-based (Railway, Fly.io)
Just a static site? → Serverless (Vercel, Netlify)
Need enterprise features? → Render
Budget under $15/month? → Seenode or self-hosted

The One Thing Everyone Gets Wrong

People compare features. They should compare billing models.

Your choice is almost never about:

"Which has the best dashboard?"
"Which supports my framework?"
"Which has the nicest CLI?"

Most modern PaaS providers have reasonable dashboards, support the common languages and frameworks, and give you some batteries-included tooling. The real question is:

Which billing model matches your traffic pattern and your budget anxiety tolerance?

If you choose the wrong model, the platform can be technically great and still feel terrible to use, because every deploy becomes a question of, "What will the bill look like next month?"

Migrating from Heroku?

If you're coming from Heroku's free tier, the biggest shock is usually the cost. Heroku's free tier spoiled us—most alternatives start at $4–20/month. The good news: you're getting better performance, more predictable uptime, and actual support.

The closest "drop-in" replacements are Railway (similar workflow) and Seenode (similar economics). Render feels more "enterprise" but costs more.

The Three Billing Models That Emerged

Over the last few years, three dominant billing models have crystallized.

Model 1: Fixed Per-Node Tiers (Seenode, Render)

You pay a flat monthly rate for provisioned capacity. Whether your app is slammed 24/7 or idle for half the month, the bill barely moves.

Predictable: You know roughly what next month’s invoice will be.
Simple: You pay for the size and count of services and databases, not for each individual CPU cycle.
Wasteful at low usage: You still pay even when your app is mostly idle.

Best for: Steady traffic, budget-conscious teams, and people who hate billing surprises.

Example costs (Jan 2026):

Seenode: $4/month (Basic web + Tier 1 Postgres)
Seenode: $11/month (Standard web + Tier 2 Postgres)
Render: $13/month (Starter web + Basic Postgres)

If your app is always on and has relatively consistent traffic, fixed tiers tend to win. You trade theoretical efficiency for billing sanity.

Model 2: Usage-Based Metering (Railway, Fly.io)

You pay for what you actually use: per-minute compute, per-second CPU, per-request, per-GB of storage and bandwidth.

Efficient at low/variable usage: Quiet apps can be very cheap.
Scales smoothly with traffic: Spikes cost more, but you do not need to resize instances manually.
Unpredictable: If you do not monitor usage, bills can drift or spike.

Best for: Variable traffic, developers who monitor usage, or apps that must be 24/7 online but receive low or bursty traffic.

Example costs (Jan 2026):

Railway: $20–30/month typical (Pro plan with $20 included credit), can spike to $50+ with sustained traffic.
Fly.io: $0–15/month for hobby apps without managed Postgres, $43–50/month once you add managed Postgres.

Usage-based systems reward teams that:

Instrument and monitor their apps.
Understand their baseline traffic profile.
Are willing to occasionally dig through billing dashboards.

If that doesn't describe you, this model can feel like a tax audit every month.

Model 3: Serverless (Vercel, Netlify)

You pay per function invocation. There is no persistent application process; instead, your code runs on demand in short-lived serverless functions.

Amazing for JAMstack: Static-first sites, Next.js, Astro, Remix, etc.
Great for spiky traffic: You only pay when people actually hit your endpoints.
Awkward for stateful backends: Long-lived connections, background jobs, or session-heavy apps do not fit naturally.

Best for: JAMstack apps, modern React frameworks, marketing sites, and dashboards with lightweight APIs.

Not suitable for: Traditional backend frameworks like Django, Rails, or Express apps that rely on in-memory state, sticky sessions, or complex background processing.

If your mental model of “backend” is a long-running process with queues, WebSockets, and custom workers, serverless can feel like fighting the platform instead of using it.

What It Actually Costs (Real Numbers, Jan 2026)

To make this concrete, consider a typical full-stack app:

Web service with roughly 1 GB RAM
Managed Postgres with 1 GB storage (plus sensible defaults)

Here is what that looks like across platforms today:

Platform	Monthly Cost	Billing Model	What You Get
Seenode	$11	Fixed tier	Standard web + Tier 2 Postgres, always-on
Fly.io	$12–15	Usage-based	Self-managed Postgres (or $43–50/month with managed Postgres)
Railway	$20–30	Usage-based	Pro plan with $20 credit, can spike with traffic
Render	$57+	Fixed tier	Web service + Postgres with PITR and zero-downtime deploys

The cliff nobody mentions: Fly.io looks cheap ($0–15) for hobby apps without managed Postgres, but once you turn on managed Postgres, the bill often jumps up rather fast ($45-50). The platform is still good—but the mental model of it being "cheap" quietly disappears.

The Decision Framework

Stop comparing dashboards and feature checklists. Walk through these questions instead.

Question 1: Can you tolerate variable billing?

Yes, I monitor usage and I am okay with variance

Choose Railway or Fly.io. You get flexible scaling and can squeeze out cost efficiencies if you understand your workload.
No, I need predictable monthly costs

Choose Seenode or Render. Fixed tiers mean you know the number before the invoice arrives.

If you feel stress every time a cloud bill arrives, treat predictability as a core feature—not a nice-to-have.

Question 2: What is your budget ceiling?

Use this as a rough mapping for a single production app with a database:

$5–15/month
- Seenode (Basic or Standard tiers: $4–11/month)
- Self-hosted on a low-cost VPS (Hetzner, Contabo, etc.), if you are willing to manage infra.
$20–50/month
- Railway (Pro plan, potentially higher with sustained traffic)
- Seenode higher tiers if you need more resources but want fixed pricing.
$50–100/month
- Render (app + managed Postgres with PITR)
- Fly.io with managed Postgres and multi-region setups.
$100+/month
- Render with enterprise-style features (SSO, high availability, advanced backups).

These numbers change over time, but the shape of the tradeoffs does not.

Question 3: Do you need enterprise features?

Yes – compliance, SOC2, SSO, PITR, zero-downtime deploys are non-negotiable

Lean toward Render. It is opinionated, boring in the best way, and designed for teams that want stability and support more than they want to save $20/month.
No – I mostly need HTTPS, logs, deploys, and a Postgres database

Seenode or Railway are usually a better fit. They give you the essentials without pushing you up into enterprise pricing.

If legal and compliance teams are involved, the cheapest platform is rarely the right one.

Question 4: Is global distribution critical?

Yes – my users are spread across regions and latency matters

Fly.io shines here, with multi-region deployments as a first-class concept.
No – most users are in one region and latency is fine

Seenode, Railway, or Render will do the job. Focus on simplicity and billing, not on global replicas you may never need.

What I Actually Use (and Why)

Disclosure: I work on Seenode, so understand the bias. That said, here is the honest breakdown of what I reach for in different scenarios.

For hobby projects

Choice: Seenode Basic ($4/month)
Why: It is the cheapest always-on option with a database included that still feels like Heroku. I can git push, get HTTPS and logs, and forget about it. At $4/month, it is psychologically close to “free” but without the randomness of free-tier shutdowns.

For client projects

Choice: Render
Why: Clients pay for peace of mind. Render gives you:
- Managed Postgres with point-in-time recovery (PITR)
- Zero-downtime deploys
- A mature, predictable environment

The extra cost (often $57+/month for a typical setup) is easy to justify compared to the cost of a single outage for a paying client.

For high-traffic production on a coffee-priced budget

Choice: Self-hosted on Hetzner (or similar low-cost VPS) with Coolify or Dokploy.

If you need:

Many services
Heavy background workers
Higher traffic

…and still want to stay under $50/month, managed PaaS platforms become harder to justify. Self-hosting:

Compresses all infra cost into a single VPS bill.
Gives you full control over resource allocation.
Moves all responsibility for uptime onto you.

Downtime in this model is almost always your fault—bad deploys, poor monitoring, slow incident response. You save money but pay in operations time and cognitive load.

The Missing Costs Nobody Mentions

Looking only at base instance prices hides a lot of real-world cost. Four common gotchas:

Common mistake: Picking a platform based on the cheapest headline price, then getting surprised by egress fees, backup costs, or usage spikes. Always factor in the hidden costs.

1. Egress fees

Railway: $0.05/GB outbound
Fly.io: $0.02/GB outbound

If you run a webhook-heavy app, file-serving API, or anything data-intensive, egress can quietly add $50–200/month on top of your compute bill.

2. Railway’s credit system

Hobby: $1/month subscription with $5 usage credit
Pro: $20/month subscription with $20 usage credit

Once your actual usage exceeds that credit, metered charges apply. For small apps this is fine; for growing usage it can turn into an invisible ratchet until you look closely at the billing breakdown.

3. Stopped machines and storage

Fly.io continues billing storage even when machines are stopped: around $0.15/GB/month.

Stopping everything in a panic does not always reset the bill to zero. Persistent volumes, snapshots, and images keep ticking along until you explicitly delete them.

4. Database backups and safety nets

Render: Includes PITR on paid database plans. This is a genuine safety feature.
Railway / Fly.io: You usually need to:
- Configure backups yourself, or
- Rely on third-party tools, or
- Accept a more limited restore story.

This is invisible until something goes wrong—and then it is the only line item that matters.

The Closest Alternatives to OG Heroku

If what you really want is “git push and boom, we are live”, here is how the modern landscape looks:

Railway – Captures a lot of the Heroku magic. Simple, fast to onboard. The tradeoff is billing unpredictability if you are not watching usage.
Seenode – Leans into Heroku-style simplicity with Heroku-free-tier-style economics. At $4/month, it is psychologically very close to the old “free dyno” experience.
Render – The most production-ready choice, especially for serious projects and client work. More expensive, but you get strong defaults and guardrails.

Everything else in the ecosystem is either:

More serverless and front-end centric (Vercel, Netlify), or
More infra-heavy and DIY (Cloud providers, raw Kubernetes, self-hosting).

They can be great—but they are no longer "Heroku for everyone."

Quick Comparison Summary

Platform	Best For	Monthly Cost	Billing Model	Key Differentiator
Seenode	Hobby projects, predictable costs	$4–11	Fixed	Cheapest always-on with DB
Railway	Variable traffic, Heroku-like workflow	$20–30+	Usage-based	Simplicity + flexibility
Render	Client work, enterprise needs	$57+	Fixed	Production-ready defaults
Fly.io	Global distribution, bursty traffic	$0–50+	Usage-based	Multi-region by default

Key Takeaways

Billing model matters more than features — Match it to your traffic pattern
Hidden costs add up — Egress, storage, backups can double your bill
Predictability vs. flexibility — Choose based on your tolerance for billing surprises
Enterprise features cost money — Only pay for them if you actually need them
Self-hosting saves money — But you pay in operational overhead

So… What Should You Actually Do?

When choosing a PaaS in 2026, ask yourself one question first:

Is predictable billing or pay-as-you-go flexibility more important for this project?

Then layer on:

How much operational burden am I willing to accept?
Do I actually need global distribution, or does a single region work?
Is this a hobby app, client app, or revenue-critical system?

Once you answer those honestly, the "Heroku alternatives" list narrows itself down very quickly.

Use this checklist as you evaluate providers:

Your stack (language, framework, database)
Rough traffic pattern (requests/day or month)
Maximum monthly budget
Whether you need enterprise features (compliance, SSO, etc.)

With clear answers to those questions, you can quickly narrow down to one or two platforms whose billing models actually fit how your app is used.

Script automation explained – what it is, tools, benefits, and real examples

rising_segun — Sun, 17 Aug 2025 16:41:00 +0000

Script automation is the use of code, written in languages such as Bash, Python, or PowerShell, to automate repetitive or time‑consuming tasks in IT operations, system administration, and software development. Instead of performing tasks manually, teams can run scripts to trigger processes such as application deployment, data backups, file transfers, or system monitoring.

Many businesses adopt script automation to reduce human error, save time, improve efficiency, and accelerate DevOps workflows. As the demand for faster software delivery and continuous integration/continuous deployment (CI/CD) grows, script automation has become an essential part of modern DevOps strategies.

In this article, we explore the key benefits of script automation, popular scripting languages, top tools, and real‑world examples to help you apply it effectively in your DevOps and IT operations.

Best Scripting Languages for Automation
Benefits of Script Automation
Top 5 Script Automation Tools
- CloudRay
- ScriptRunner
- Ansible
- AttuneOps
- Jenkins
Examples of Script Automation in Bash
Wrapping up

Best Scripting Languages for Automation

There are several programming languages for script automation with unique strengths and characteristics. However, Bash scripting and Python remain the most widely used for system and DevOps automation.

Bash scripting: This is a shell command language known for its integration with Unix-based systems. It’s ideal for automating administrative tasks such as package installation, server bootstrapping, or even deployments.
Python: This is a high-level and general purpose language widely used for infrastructure automation, API scripting, and test pipelines in modern DevOps workflows.

Both Bash and Python have strengths and weaknesses depending on the use case. Below is a brief comparison:

Feature	Bash	Python
Best for	Shell scripting, Linux/Unix system tasks	Cross-platform automation, APIs, DevOps Workflows
Ease of Use	Simple for basic tasks; can get complex for logic-heavy work	Readable and maintainable, especially for large scripts
Tooling & Ecosystem	Native to Unix/Linux; tightly integrated with CLI tools	Rich library ecosystem for HTTP, automation, DevOps, etc.
Performance	Fast for command chaining and shell operations	Slightly slower but better for complex logic and data parsing
Error Handling	Primitive error handling (exit codes)	Built‑in exception handling
Learning Curve	Easier for those familiar with Linux shell	Easier for general-purpose programming and logic-heavy tasks

Aside from Bash and Python, there are several other scripting languages for automation with each with it’s unique use cases. Here are other scripting languages widely used for IT operations and DevOps automation:

Go (Golang): It’s unique for task concurrent executions
PowerShell: Designed for windows automation which is great for managing system configurations and registry task
Java: Often used for DevOps pipeline automation and integrations
Ruby: popular for automating configuration management
Perl: Powerful for file processing and text manipulation
JavaScript: Useful for automating web APIs or build processes

Each of these scripting languages offers unique strengths and limitations with each one best known for specific automation.

Benefits of Script Automation

The benefits of script automation are significant. As businesses scale their infrastructure and software operations, manual processes become time‑consuming, tedious, and error‑prone. Script automation boosts productivity, reduces human error, and accelerates software delivery and deployments.

Here are some benefits of using script automation in DevOps workflows and IT environments:

Cost Optimisation: Generally, script automation reduces the need for human input which eventually cuts down human work hours and minimize costly mistake. Teams saves both time and money by automating routine tasks.
Faster Tasks Execution: Automation can execute tasks in minutes even seconds compared to manual efforts which can take hours or days to execute. Script automation leads to faster incident recovery, deployments, and even overall performance.
Improved Accuracy and consistency: Manual operation is error prone. However, with script automation, operations are executed with consistency across various environments.
Enhanced Productivity: Script automation frees up teams from repetitive tasks. This allows team to focus on higher priority work such as innovation, workflow optimisation, and security hardening.
Seamless Integration with DevOps Tools Scripts can be easily integrated with CI/CD and configuration management tools. They can work with this tools efficiently to trigger deployments, automate test run, and so on.

Top 5 Script Automation Tools

Script automation tools has become important for teams that want to scale faster, increase productivity, and optimise costs. These tools empowers DevOps engineers, system admins, and cloud engineers to streamline operations.

Here are top five best script automation tool used by modern engineering teams:

CloudRay

CloudRay is a centralised Bash script automation platform that allows team to manage cloud and hybrid infrastructure. It allows team to run Bash scripts securely across hybrid or cloud infrastructure with the help of an Agent. This unique feature makes it suitable for automating repetitive infrastructure tasks such as Installations, deployments, server maintenance, backups and other infrastructure tasks.

Additionally, CloudRay’s schedules allow teams to schedules scripts across multiple environments. It also supports webhook triggers, making automation repeatable and event-driven. CloudRay stands out by combining the flexibility of scripting with the governance enterprise teams need to scale securely.

ScriptRunner

ScriptRunner is an automation platform specifically designed for PowerShell. It’s used by Windows admins to automate routine admin tasks with full auditability and governance. It provides a centralised environment for storing, managing, and executing PowerShell scripts with control and traceability. This tool also supports approvals, Active Directory integration, and delegated execution and logging.

Ansible

Ansible is an open source configuration management tool developed by Red Hat. It uses YAML-based playbooks for infrastructure wide automation and is popular for managing complex infrastructure at scale. Ansible unique characteristics is its agentless nature in which it can operate over SSH allowing easier adoption.

AttuneOps

AttuneOps is a script automation tool that provides advanced orchestration, scheduling and workflow management. It supports multiple scripting languages such as PowerShell, Bash, and Python.

It provides a centralised engine that allows team to automate across different OS environment consistency. It is used heavily in IT operations allowing teams to manage routine and repetitive tasks.

Jenkins

Jenkins is the widely used automation platform for CI/CD in DevOps workflow. It excels at executing automation scripts and scheduled jobs. Jenkins supports multiple scripts such as shell and Python script. This integrates with the source control tools, and offers robust scheduling workflows.

Examples of Script Automation in Bash

Bash script can be used to automate routine system administration tasks. These tasks can be installation of packages, database backups, provisioning of servers, and deployments.

Let’s look at some practical examples of Bash script automation that improves IT operations and DevOps workflows:

1. Automating LAMP Stack Installations

Bash script can be used to set up web servers quickly. You can automate the installation of LAMP stack (Linux, Apache, MySQL, PHP).

#!/bin/bash

set -e

# Update package list and install LAMP stack
sudo apt update
sudo apt install apache2 mysql-server php libapache2-mod-php -y

# Start services
sudo systemctl enable apache2
sudo systemctl enable mysql

This script will install all the required components needed and ensures Apache and MySQL automatically starts on system reboot.

2. Automating MySQL Backups to S3

Bash script can be used to automate and schedule routine database backup. For example, you can automate MySQL backups to Amazon S3 to ensure your data is consistently available offsite.

#!/bin/bash

set -e

# Variables
DB_NAME="mydb"
USER="root"
PASSWORD="yourpassword"
BACKUP_PATH="/tmp/mysql-backup.sql"
DATE=$(date +%F)

mysqldump -u $USER -p$PASSWORD $DB_NAME > $BACKUP_PATH
aws s3 cp $BACKUP_PATH s3://your-s3-bucket/$DB_NAME-$DATE.sql

You can also use it to automate backup of PostgreSQL to S3.

3. Automating Installation of WordPress

You can use Bash script to streamline and automate the deployment of CMS platform like WordPress. For example, you can automate the deployment of multiple WordPress site on a single server with the use of Bash script.

#!/bin/bash

set -e

# Update package list and install LAMP stack
sudo apt update
sudo apt install apache2 mysql-server php php-mysql -y

# Create directories for multiple sites
sudo mkdir -p /var/www/site1.com /var/www/site2.com

# Set permissions
sudo chown -R $USER:$USER /var/www/site1.com /var/www/site2.com

# Download and extract WordPress
wget https://wordpress.org/latest.tar.gz
tar -xvzf latest.tar.gz
cp -r wordpress/* /var/www/site1.com

Additionally, you can also use Bash script to automate the backup process of your WordPress site.

4. Deploy a Database Server

infrastructure engineers use Bash scipt to save time during infrastructure setup. You can use Bash script to automate the deployment of MySQL server on a Linux host.

#!/bin/bash

set -e

# Update package list and install MySQL server
sudo apt update
sudo apt install -y mysql-server
sudo systemctl enable mysql
sudo systemctl start mysql

Wrapping up

Script automation is an efficient way for DevOps and IT professionals to streamline DevOps tasks, IT operations, and reduce the likelihood for human error. Whether you’re automating deployments, backups, or security checks, having a well-structured approach enhances productivity and reliability. As infrastructure grow, so does the complexity to manage these growth. Script automation becomes not just a convenience but a necessity.

CloudRay is a leading platform for centralised Bash script automation across your cloud and server infrastructure. With CloudRay Agent, you can securely connect your cloud instances and on-premise servers, enabling real-time execution and monitoring of scripts from a single control panel. Our powerful Schedules feature allows you to automate scripts at custom intervals, whether hourly, daily, or triggered by specific events ensuring your DevOps workflows run reliably without manual intervention. CloudRay simplifies script management, increases operational efficiency, and gives teams full control over infrastructure automation, all from one unified interface.

Get Started with CloudRay

How to Automate AWS EC2, Backups and Monitoring Using Bash Scripts

rising_segun — Fri, 23 May 2025 00:00:00 +0000

Automating AWS infrastructure is a key practice for modern DevOps teams and cloud engineers. While Infrastructure as Code (IaC) tools like Terraform and CloudFormation have become the industry standard, Bash scripting remains a powerful and accessible way to automate AWS tasks. Bash scripts is especially useful for teams that wants lightweights, fast, and scriptable workflows without the overhead of learning a new Domain Specific Languages (DSL).

In this article, you will learn how to automate common AWS tasks using plain Bash scripts combined with AWS CLI. Whether you’re launching EC2 instances, taking automated EBS snapshots, or setting up monitoring scripts to track CPU utilisation, Bash provides a direct and flexible approach to get things done quickly. At the end, you will learn real-world use case on how to use bash script based automation more effectively using CloudRay a centralised platform for managing, scheduling, executing, and organising your scripts across environments.

Automation Use Cases
- 1. Automating EC2 Instance Launch with Bash Script
- 2. Automating EBS Volume Backups with Bash Script
- 3. Monitoring EC2 CPU Utilisation with Bash Script
Real World Use Case of Automating AWS Infrastructure using CloudRay
- EC2 Instance Launch with Auto-Tagging and Bootstrapping
- Running the Script on a Schedule with CloudRay
Wrapping Up

Automation Use Cases

AWS automation is not limited to large-scale infrastructure provisioning. With just Bash and the AWS CLI, you can automate a variety of real-world tasks such as launching of instances, backing up data, and monitoring system performance. These use cases are useful when you need a quick scripts to integrate into cron jobs, CI/CD pipelines, or even internal tools.

To follow along, ensure that your AWS CLI is properly installed and configured. If not, refer to the AWS CLI Setup Guide for a complete walkthrough on installing the CLI, creating key pairs, and configuring credentials.

Below are some of the most practical AWS automation tasks you can implement using Bash scripts.

1. Automating EC2 Instance Launch with Bash Script

Automating the creation, termination, and monitoring of EC2 instance is a common use case of AWS infrastructure management. With a simple bash script, you can reduce the manual steps and repeatability especially when managing development, staging, or even short-lived workloads for testing.

To begin, create a bash script file named launch-ec2:

nano launch-ec2

Add the following script to the file to launch EC2 instance, wait for it to become available, retrieve public IP address, and list the attached EBS volumes of the instance:

#!/bin/bash

# Launch a new EC2 instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id ami-084568db4383264d4 \ # Replace with your preferred AMI
  --count 1 \
  --instance-type t2.micro \
  --key-name my-production-key \ # Replace with your existing key name
  --security-group-ids sg-0269249118de8b4fc \ # Replace with your Security Group ID
  --query 'Instances[0].InstanceId' \
  --output text)

echo "Launched EC2 Instance with ID: $INSTANCE_ID"

# Wait until instance is running
aws ec2 wait instance-running --instance-ids $INSTANCE_ID
echo "Instance is now running."

# Fetch public IP address
PUBLIC_IP=$(aws ec2 describe-instances \
  --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

echo "Public IP Address: $PUBLIC_IP"

# Get associated EBS Volume ID
VOLUME_ID=$(aws ec2 describe-instances \
  --instance-ids $INSTANCE_ID \
  --query 'Reservations[0].Instances[0].BlockDeviceMappings[0].Ebs.VolumeId' \
  --output text)

echo "EBS Volume attached to instance: $VOLUME_ID"

Here is what the script does:

launches an EC2 instance with a specified AMI, instance type, key pair, and security group
Waits for the instance to become active before proceeding
Retrieves and display public IP for SSH access or web server testing
Fetches the EBS Volume ID for later automation (e.g., backup snapshots or monitoring usage)

TIP

Make sure you replace the AMI and security group in the script with your own AMI and security group. To get the AMI, navigate to the EC2 Console, select AMIs from the sidebar, and use filters to locate the Amazon Linux or Ubuntu image you would like to use (copy its AMI ID)

Next, make your script executable:

chmod +x launch-ec2

Finally you can run the scripts:

./launch-ec2

Your result would be similar to the below

This shows that the instance was created successfully and both the IP address and the EBS volume is displayed. To confirm further, you can check the AWS console.

You can see the EC2 instance running successful.

2. Automating EBS Volume Backups with Bash Script

Another critical automation task is backing up your Elastic Block Store (EBS) volumes. Regular backups ensure you can recover your data in the event of accidental deletion, instance failure, or security breaches.

With a Bash script, you can create snapshots of your EBS volumes on demand or integrate them into a scheduled cron job for automated backups.

To get started, create a script named backup-ebs.sh:

nano backup-ebs.sh

Now add the following script to automate the creation of a snapshot for a given volume and tag it for easier identification:

#!/bin/bash

# Configuration
VOLUME_ID="vol-04fa2bf1eb229e072" # Replace with your volume ID
DESCRIPTION="Backup on $(date '+%Y-%m-%d %H:%M:%S')"
TAG_KEY="Purpose"
TAG_VALUE="AutomatedBackup"

echo "Creating snapshot of volume: $VOLUME_ID"

# Create snapshot
SNAPSHOT_ID=$(aws ec2 create-snapshot \
  --volume-id $VOLUME_ID \
  --description "$DESCRIPTION" \
  --query 'SnapshotId' \
  --output text)

echo "Snapshot created with ID: $SNAPSHOT_ID"

# Add tags to the snapshot
aws ec2 create-tags \
  --resources $SNAPSHOT_ID \
  --tags Key=$TAG_KEY,Value=$TAG_VALUE

echo "Snapshot $SNAPSHOT_ID tagged with $TAG_KEY=$TAG_VALUE"

Here is what the script does:

Takes a snapshot of a specified EBS volume using the AWS CLI
Adds a human-readable description that includes the date and time of the backup
Applies tags to the snapshot so you can easily search or filter for it in the AWS console

TIP

To find your EBS Volume ID, go to the EC2 Console → Volumes → and look under the “Volume ID” column. Be sure to copy the correct volume attached to your running instance.

Again, make the script executable:

chmod +x backup-ebs.sh

Finally, run the script:

./backup-ebs.sh

If successful, the output should display the snapshot ID along with a confirmation that it has been tagged

This backup script is a great candidate for CloudRay’s scheduler feature allowing you to run it every day, week, or hour without needing a separate server or cron job setup.

3. Monitoring EC2 CPU Utilisation with Bash Script

System performance monitoring is essential for maintaining the health and stability of your applications. While AWS CloudWatch provides detailed metrics and dashboards, you can also automate metric checks using a simple Bash script

One common metric to monitor is CPU utilisation. By querying CloudWatch, we can track when an EC2 instance’s CPU usage spikes above a defined threshold and respond accordingly.

Start Start by creating a script file named monitor-cpu.sh:

nano monitor-cpu.sh

Then paste the following code into the file:

#!/bin/bash

# Configuration
INSTANCE_ID="i-044166a99d5666bfc" # Replace with your instance ID
CPU_THRESHOLD=70 # Trigger alert if CPU > 70%
TIME_RANGE_MINUTES=60 # How far back to check

# Fetch CPU Utilisation
CPU_UTILISATION=$(aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilisation \
  --statistics Maximum \
  --period 300 \
  --start-time $(date -u -d "$TIME_RANGE_MINUTES minutes ago" +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --dimensions Name=InstanceId,Value=$INSTANCE_ID \
  --query 'Datapoints | sort_by(@, &Timestamp)[-1].Maximum' \
  --output text)

# Show retrieved metric
echo "CPU Utilisation for instance $INSTANCE_ID: $CPU_UTILIZATION%"

# Check against threshold
if (( $(echo "$CPU_UTILISATION > $CPU_THRESHOLD" | bc -l) )); then
  echo "⚠️ High CPU alert: $INSTANCE_ID at $CPU_UTILISATION%"
else
  echo "✅ CPU usage is within safe range."
fi

Here is what the script does:

Retrieves the maximum CPU utilisation from the last hour for a specific EC2 instance using CloudWatch metrics
Compares it to a defined threshold (For example, 70%)
Prints an alert if the usage exceeds the threshold, or a success message if within range

Make the script executable:

chmod +x monitor-cpu.sh

Finally, run the script:

./monitor-cpu.sh

Your result would be similar to the below

This lightweight monitoring script is perfect for integrating with a scheduled task on CloudRay. You can set it to run every 15 minutes and trigger custom actions like Slack alerts, emails, or remediation scripts whenever thresholds are breached.

Real World Use Case of Automating AWS Infrastructure using CloudRay

While Bash scripting gives you a powerful tool to automate AWS tasks locally, managing and reusing these scripts across environments becomes tedious without a centralised system. That is where CloudRay comes in.

CloudRay provides a Scripts dashboard where you can centrally manage, execute, and reuse your infrastructure automation scripts without relying on manual CLI or scattered cron jobs. it supports scheduling, allowing you to trigger EC2 provisioning or any AWS operation at predefined times.

Let’s walk through a real-world scenario where a DevOps engineer needs to launch a pre-configured EC2 instance every morning for development testing.

EC2 Instance Launch with Auto-Tagging and Bootstrapping

Before getting started, make sure your target servers are connected to CloudRay. If you haven’t done this yet, follow our servers docs to add and manage your server.

You can follow the below steps to create the script in CloudRay:

Create a CloudRay account at https://app.cloudray.io/
Go to Scripts > New Script
Name: Launch EC2 for Daily Dev Testing
Add code:

#!/bin/bash

# Optional: user data script (e.g., install NGINX on launch)
USER_DATA_SCRIPT='#!/bin/bash
sudo apt update -y
sudo apt install -y nginx
sudo systemctl enable nginx
sudo systemctl start nginx
'

echo "[$(date)] Starting EC2 launch process..." | tee -a {{log_file}}

# Launch EC2 instance
INSTANCE_ID=$(aws ec2 run-instances \
  --image-id "{{ami_id}}" \
  --count 1 \
  --instance-type "{{instance_type}}" \
  --key-name "{{key_name}}" \
  --security-group-ids "{{security_group_id}}" \
  --block-device-mappings "[{\"DeviceName\":\"/dev/xvda\",\"Ebs\":{\"VolumeSize\":{{volume_size}}}}]" \
  --tag-specifications "ResourceType=instance,Tags=[{Key=Name,Value={{tag_name}}},{Key=Environment,Value={{environment}}}]" \
  --user-data "$(echo -n "$USER_DATA_SCRIPT" | base64 -w 0)" \
  --query 'Instances[0].InstanceId' \
  --output text)

if [[-z "$INSTANCE_ID"]]; then
  echo "[$(date)] Failed to launch instance." | tee -a {{log_file}}
  exit 1
fi

echo "[$(date)] Launched instance: $INSTANCE_ID" | tee -a {{log_file}}

# Wait until running
echo "[$(date)] Waiting for instance to enter running state..." | tee -a {{log_file}}
aws ec2 wait instance-running --instance-ids "$INSTANCE_ID"
echo "[$(date)] Instance is running." | tee -a {{log_file}}

# Fetch public IP
PUBLIC_IP=$(aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

LAUNCH_TIME=$(aws ec2 describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].LaunchTime' \
  --output text)

echo "[$(date)] Public IP Address: $PUBLIC_IP" | tee -a {{log_file}}
echo "[$(date)] Launch Time: $LAUNCH_TIME" | tee -a {{log_file}}

# Output summary
echo ""
echo "================= EC2 Instance Launched ================="
echo "Instance ID : $INSTANCE_ID"
echo "Public IP : $PUBLIC_IP"
echo "Launch Time : $LAUNCH_TIME"
echo "Tag Name : {{tag_name}}"
echo "Environment : {{environment}}"
echo "========================================================"

This script provisions a fully tagged EC2 instance, installs NGINX on launch, and logs key metadata for auditing or monitoring.

Before running the scripts, you need to define values for the placeholders {{ami_id}}, {{instance_type}}, {{key_name}} {{security_group_id}}, and {{volume_size}} used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

ami_id: This is the AMI ID of your instance type (In this case it could be Ubuntu or any other operating system)
instance_type: This is the type of instance you want to use
key_name: The name of your private key in your AWS account
security_group_id: This is your security group ID
volume_size: The size of your EBS volume in GB

You can choose to run the script using CloudRay’s Script Playlists.

CloudRay uses Runlogs to execute scripts on your servers while providing real-time logs of the execution process.

To run the Launch EC2 for Daily Dev Testing, follow these steps:

Navigate to Runlogs : In your CloudRay project, go to the Runlogs section in the top menu.
Create a New Runlog : Click on New Runlog.
Configure the Runlog : Fill in the required details:

Server: Select the server you added earlier.
Script: Choose the “Launch EC2 for Daily Dev Testing”
Variable Group (optional): Select the variable group you created earlier.
Execute the Script : Click on Run Now to start the execution.

CloudRay will automatically connect to your server, run the Launch EC2 for Daily Dev Testing, and provide live logs to track the process. If any errors occur, you can review the logs to troubleshoot the issue.

You can Verify the instance also from the AWS console.

Running the Script on a Schedule with CloudRay

CloudRay also offers Schedules, allowing you to execute scripts automatically at specific intervals or times.

To execute this script daily at 8:00 AM without manual effort:

Navigate to Schedules: In your CloudRay dashboard, go to the “Schedules” tab.
Click “Add Schedule”: Start creating a new schedule.
Submit Schedule: Click “Submit” to activate your new schedule.

CloudRay will automatically execute the backup script at the scheduled time, ensuring that your EC2 instance is launched regularly everyday at 8AM.

Wrapping Up

Bash scripting provides a lightweight yet powerful way to automate AWS infrastructure tasks like EC2 provisioning, EBS backups, and performance monitoring. By combining these scripts with CloudRay’s scheduling and central management, you can build reliable, automated workflows without complex tooling. Start with the examples provided, customize them for your needs, and explore more automation possibilities.

Start today by signing up at https://app.cloudray.io and managed your bash scripts in a centralised platform.

Automating Web App Deployment with Terraform, GitHub, and CloudRay

rising_segun — Thu, 10 Apr 2025 10:50:50 +0000

CloudRay makes it easy to automate application deployment across your infrastructure. Instead of juggling manual steps or switching between tools, you can integrate CloudRay with Terraform and GitHub to build a seamless deployment pipeline.

In this tutorial, you will learn how to use Terraform to provision infrastructure on DigitalOcean, and then configure CloudRay to automate the deployment and management of a Node.js application. Additionally, You will also learn how to implement a simple CI/CD pipeline using GitHub Actions and CloudRay webhook, so every push to your repository automatically triggers a deployment.

By the end, you’ll have a fully automated system that provisions a server, deploys your web app, and keeps it updated with zero manual effort.

Prerequisites
Provisioning Infrastructure with Terraform
Configuring CloudRay for Automated Deployments
- Creating Deployment Script and CloudRay Webhook
- Integrating CloudRay Webhook in Terraform
Setting Up Continuous Deployment with GitHub and CloudRay
Conclusion

Prerequisites

Before you begin, ensure you have the following set up:

Terraform installed: You can install Terraform by following the official instructions
CloudRay account: Sign up at https://app.cloudray.io
DigitalOcean Personal Access Token: Create one via your DigitalOcean control panel. You will need this to authenticate Terraform with DigitalOcean
SSH key added to your DigitalOcean account: Create and upload a key using this guide. Make note of the name you assign—it will be used in your Terraform configuration
GitHub repository with a sample Node.js app: For this tutorial, we’ll use a sample Node.js app stored in GitHub. You can fork and clone this starter app or use your own

Provisioning Infrastructure with Terraform

Terraform lets you define infrastructure as code and supports a wide range of platforms through installable providers. Each provider acts as a bridge between Terraform and the APIs of the service you’re provisioning—like DigitalOcean in our case.

We will start by using Terraform to provision a virtual machine (droplet) on DigitalOcean. This will serve as the host for our Node.js application.

First, you create a project directory to house your infrastructure configuration files and navigate into the file:

mkdir infra-cloudray && cd infra-cloudray

Next, before running any terraform command, set the following environment variables to pass in your private SSH key and DigitalOcean API token securely. Replace the token value with your own generated token from the DigitalOcean dashboard:

export TF_VAR_pvt_key="~/.ssh/id_ed25519"
export TF_VAR_do_token="dop_v1_XXXXXXXXXXXXXXXXXXXXXXXXXXXX"

TIP

TF_VAR_ prefix allows you to pass environment variables to Terraform as input variables

Create a file named provider.tf which stores the configuration of the provider:

nano provider.tf

Then add the following configuration into the file:

terraform {
  required_providers {
    digitalocean = {
      source = "digitalocean/digitalocean"
      version = "~> 2.0"
    }
  }
}

provider "digitalocean" {
  token = var.do_token
}

data "digitalocean_ssh_key" "my_key" {
  name = "my_key"
}

This file sets up the Terraform provider configuration, which tells Terraform to use the DigitalOcean plugin and specifies your authentication token. Replace my_key with the exact name you used when uploading your SSH key to DigitalOcean.

Create the second file named variable.tf:

nano variables.tf

Add the following configurations into the file:

variable "do_token" {
  description = "DigitalOcean API token"
  type = string
  sensitive = true
}

variable "pvt_key" {
  description = "Path to the private SSH key"
  type = string
  default = "~/.ssh/id_ed25519"
}

This file declares input variables, including the DigitalOcean API token and your SSH private key path.

Finally, create the main infrastructure file named www-cloudray.tf:

nano www-cloudray.tf

Similarly, add the following configuration inside the file:

resource "digitalocean_droplet" "www-cloudray" {
  image = "ubuntu-24-10-x64"
  name = "www-cloudray"
  region = "nyc3"
  size = "s-1vcpu-1gb"
  ssh_keys = [
    data.digitalocean_ssh_key.my_key.id
  ]

  connection {
    host = self.ipv4_address
    user = "root"
    type = "ssh"
    private_key = file(var.pvt_key)
    timeout = "2m"
  }
}

This is the main infrastructure file where we define our server. We use Ubuntu 24.10 and connect via SSH using your uploaded key. Furthermore, the configuration tells terraform to create a droplet named “www-cloudray”, use the SSH key you added to DigitalOcean and automatically connect connect using SSH for further provisioning.

Now, you initialize the terraform file:

terraform init

Next, you run the terraform plan to see your execution plan:

terraform plan

The + resource "digitalocean_droplet" "www-cloudray" shows that terraform will create a droplet resources named www-cloudray. Then, apply the configuration by running the command:

terraform apply

When prompted, type yes to confirm.

After deployment, you can inspect the created infrastructure and get the server’s IP address using:

terraform show terraform.tfstate

Now, you can add the server to CloudRay

Configuring CloudRay for Automated Deployments

Now that your DigitalOcean droplet is provisioned and added to CloudRay, let’s automate deployments using CloudRay’s script orchestration. This section covers:

Creating a deployment script and webhook
Modifying Terraform to trigger deployment of the application

Let’s get started.

Creating Deployment Script and CloudRay Webhook

First you create the deployment script by following these steps:

To create the setup script, you need to follow this steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Deploy App Script. You can give it any name of your choice
Copy this code:

#!/bin/bash

# Update package lists
sudo apt update -y

# Install Nginx
sudo apt update 
sudo apt install -y nginx 

# Exit on error
set -e

# Install Node.js and npm
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs

# Install PM2
sudo npm install -g pm2

# Clean and clone repo
sudo rm -rf "{{app_dir}}"
sudo mkdir -p "{{app_dir}}"
sudo chown -R $USER:$USER "{{app_dir}}"
git clone "{{repo_url}}" "{{app_dir}}"

# Install dependencies
cd "{{app_dir}}/app"
npm install

# Start application
pm2 start server.js --name nodeapp
pm2 save
pm2 startup

sudo bash -c "cat > /etc/nginx/sites-available/nodeapp" <<EOF
server {
    listen 80;
    server_name {{domain}} www.{{domain}};
    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host \$host;
        proxy_cache_bypass \$http_upgrade;
    }
}
EOF

# Enable config
sudo ln -sf /etc/nginx/sites-available/nodeapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl restart nginx

# SSL with Certbot
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d {{domain}} -d www.{{domain}} --email {{email}} --agree-tos --non-interactive
sudo systemctl reload nginx

Here is a breakdown of what each command in the Deploy App Script does:

Sets up the web server and runtime environment
Clones your Node.js repository and installs dependencies
Runs app as a managed background service
Routes web traffic to your Node.js app
Automatically provisions Let’s Encrypt SSL certificates

before using the scripts, you need to define values for the placeholders {{app_dir}}, {{repo_url}}, {{domain}}, and {{email}}, used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

{{app_dir}}: This is the application install path
{{repo_url}}: This is the GitHub repository URL
domain: The registered domain name for SSL certificate configuration
email: The email address associated with the SSL certificate (used for renewal alerts)

Since the script and variables are setup, proceed to creating a Webhook for the deployment script.

To create an Incoming Webhook in CloudRay follow these steps:

In CloudRay navigate and click on “Incoming Webhooks”
Click on “New Incoming Webhook” and fill in the detials to create the Webhook
Click “Create New Webhook”. This will generate a unique URL for your webhook

Now that your deployment script and CloudRay webhook are ready, the final step is to make sure Terraform can trigger that webhook

Integrating CloudRay Webhook in Terraform

We can update our Terraform configuration to trigger the CloudRay webhook after the droplet is successfully provisioned. Instead of using the remote-exec provisioner, we use a null_resource block with a local-exec provisioner, which runs the webhook call locally from the machine running Terraform.

Update your www-cloudray.tf file:

nano www-cloudray.tf

Add the following null_resource configuration outside the droplet block:

...
resource "null_resource" "trigger_cloudray_webhook" {
  provisioner "local-exec" {
    command = <<EOT
      curl -X POST \
        https://api.cloudray.io/w/58b3b37d-a77c-4b22-a6bc-ef3e2af8af34 \
        -H "Content-Type: application/json" \
        -d '{"test": false}'
    EOT
  }

  depends_on = [digitalocean_droplet.www-cloudray]
}
...

This tells Terraform to trigger the CloudRay webhook only after the www-cloudray droplet has been successfully created.

Your updated www-cloudray.tf file should now look like this:

This approach ensures that the webhook is triggered reliably during the provisioning process without the need for SSH access into the droplet.

Before applying your changes, reinitialize your Terraform project and upgrade any modules or providers:

terraform init -upgrade

Then apply the configuration:

terraform apply

Once terraform apply completes successfully, head over to your CloudRay Runlog to confirm that the webhook was received and the deployment job ran successfully.

Open your browser and navigate to your configured domain (e.g., https://www.mydomain.com). You should now see your application live and running on the newly provisioned droplet.

Setting Up Continuous Deployment with GitHub and CloudRay

To automate your deployment pipeline, we’ll integrate GitHub Actions with CloudRay so that any push to the main branch triggers a webhook, which then updates your server with the latest code.

First, let’s create the script on CloudRay to update always update the application. You can follow similar process as the above and use this code:

#!/bin/bash
set -e # Exit immediately if any command fails

# Navigate to project root
cd /var/www/nodeapp

echo "➡️ Pulling latest changes..."
git pull origin main

# Move to app directory
cd app

echo "📦 Installing dependencies..."
npm install

echo "🔄 Restarting application..."
pm2 restart nodeapp || (pm2 delete nodeapp && pm2 start server.js --name nodeapp)

Next, we also create a Webhook following similar steps as discussed earlier

Then go to the project repository (the node.js application), create a directory and file:

mkdir -p .github/workflows
touch .github/workflows/deploy.yml

Then add the following content to .github/workflows/deploy.yml:

name: Deploy to CloudRay

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger CloudRay Webhook
        env:
          WEBHOOK_URL: ${{ secrets.CLOUDRAY_WEBHOOK }}
        run: |
          curl -X POST "$WEBHOOK_URL" \
            -H "Content-Type: application/json" \
            -d '{"test": false}'

To add your CloudRay webhook to GitHub secrets, follow these steps:

Go to your GitHub repo Settings → Secrets → Actions
Click “New repository secret”
Name: CLOUDRAY_WEBHOOK
Value: Paste your CloudRay webhook URL
Click “Add secret”

Finally, let’s test the pipeline, make a changes on the application (modify the index.html file):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Welcome</title>
</head>
<body>
    <h1>Greetings from CloudRay</h1>
    <p>This update was deployed automatically via GitHub → CloudRay 🎉</p>
</body>
</html>

Commit and push to main:

git add .
git commit -m "Test CI/CD pipeline"
git push origin main

Watch the process, GitHub Actions will show the workflow running.

Additionally, CloudRay will display the script execution in Run Logs.

Finally, visit your domain to see changes live within seconds.

Conclusion

By following this guide, you’ve successfully built a complete infrastructure automation and CI/CD pipeline that combines Terraform, DigitalOcean, CloudRay, and GitHub Actions.

The entire process from server creation to application updates now happens automatically whenever you push code changes, giving you more time to focus on development rather than deployment tasks.

Ready to streamline your own deployment workflow? Sign up for CloudRay today and experience the power of infrastructure automation firsthand.

Get Started with CloudRay

Deploy a Laravel Application using CloudRay

rising_segun — Thu, 03 Apr 2025 12:34:35 +0000

CloudRay simplifies infrastructure deployment through automation, making it an ideal choice for managing Laravel applications with Caddy. It automates the entire deployment process, reducing manual effort and ensuring a seamless, repeatable setup.

In this guide, you will learn the process of deploying a Laravel application with Caddy using CloudRay. You will learn how to create a detailed automation script for setting up the system, installing dependencies, deploying Laravel, and configuring Caddy as the web server. Caddy simplifies the process by automatically handling HTTPS (SSL/TLS) with Let’s Encrypt, ensuring your application is secure by default.

By the end of this guide, you will have a fully functional Laravel application hosted on an optimised server environment with automatic SSL support provided by Caddy.

Prerequisites
Assumptions
Create the Automation Script
- System Setup Script
- Install Composer and Database Setup Script
- Laravel Deployment Script
Create a Variable Group
Running the Script with CloudRay
Troubleshooting
Related Guides

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

A CloudRay account at https://app.cloudray.io/
A cloud server accessible via SSH: If you don’t already have a cloud server, you can get one from popular providers like AWS, DigitalOcean, and Google Cloud. Ensure the server has at least 4GB of RAM, and a minimum of 20GB SSD
SSH credentials: Ensure you have access to the necessary SSH keys or login credentials to access your server. If you don’t have an SSH key set up, follow this guide to create one and add it to CloudRay
The servers are added to CloudRay: Before proceeding, make sure your server is connected to CloudRay. If you haven’t done this yet, follow this guide to add and manage your server

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can adapt the scripts to fit your specific deployments needs and environment.

Assumptions

This guide assumes you’re using Rocky Linux 9 as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly

Create the Automation Script

To streamline the deployment process, you can use three automation scripts

System Setup Script: Installs all the Lavarel application and systems dependencies
Install Composer and Database Setup Script: Installs composer and setup the Laravel database
Laravel Deployment Script: automates cloning, configuring, and deploying a Laravel app with Caddy

Let’s begin with the System Setup Script

System Setup Script

To create the System Setup Script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: System Setup Script. You can give it any name of your choice
Copy this code:

#!/bin/bash

# exit on error
set -e

# Update system
sudo dnf update -y

# Install required software
sudo dnf install -y mariadb-server php php-fpm php-common php-xml php-mbstring php-json php-zip php-mysqlnd curl unzip nano

# Start and enable services
sudo systemctl start mariadb php-fpm
sudo systemctl enable mariadb php-fpm

# Configure PHP-FPM
sudo sed -i 's/^;listen.owner =.*/listen.owner = www-data/' /etc/php-fpm.d/www.conf
sudo sed -i 's/^;listen.group =.*/listen.group = www-data/' /etc/php-fpm.d/www.conf

sudo systemctl restart php-fpm

# Set SELinux to permissive mode
sudo setenforce 0

# Add /usr/local/bin to secure path in sudoers
sudo sed -i '/Defaults\s\+secure_path = /s|\(.*\)|\1:/usr/local/bin|' /etc/sudoers

echo "System setup complete!"

Here is a breakdown of what each command in the System Setup Script does:

Updates the system to the latest packages
Installs MariaDB, PHP, and dependencies required for Laravel
Starts and enables services to launch on boot
Configures PHP-FPM to use www-data as the owner
Configures SELinux to be permissive (optional, for easier troubleshooting)
Adds /usr/local/bin to the secure path for sudo commands

Install Composer and Database Setup Script

Next, you need to install and setup the database for the Laravel application. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: Install Composer and Database Setup Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Install Composer
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
sudo chmod +x /usr/local/bin/composer

# Verify Composer installation
composer --version

# Configure MySQL database
sudo mysql <<EOF
CREATE DATABASE {{db_name}};
CREATE USER '{{db_user}}'@'localhost' IDENTIFIED BY '{{db_pass}}';
GRANT ALL PRIVILEGES ON {{db_name}}.* TO '{{db_user}}'@'localhost';
FLUSH PRIVILEGES;
EOF

echo "Composer and MySQL setup complete!"

This is what the Install Composer and Database Setup Script does:

Installs Composer, a dependency manager for PHP
Verifies Composer installation to ensure it’s available system-wide
Configures MariaDB database by creating a database, user, and granting permissions

Laravel Deployment Script

The final script automates the cloning, configuration, and deployment of your Laravel application with Caddy. This script will handle the deployment process, ensuring your application is ready to serve traffic.

To create the Laravel Deployment Script, follow these steps:

Go to Scripts > New Script
Name: Laravel Deployment Script
Add code:

#!/bin/bash

# Exit on error
set -e

# install git
sudo dnf install git -y

# Install Caddy
sudo dnf install 'dnf-command(copr)' -y
sudo dnf copr enable @caddy/caddy -y
sudo dnf install caddy -y

# Start and enable Caddy
sudo systemctl start caddy
sudo systemctl enable caddy

# Clone Laravel project from GitHub
if [! -d "/var/www/html/{{repo_name}}"]; then
    echo "Cloning Laravel repository from GitHub..."
    sudo git clone https://{{github_access_token}}@github.com/{{github_user}}/{{repo_name}}.git /var/www/html/{{repo_name}}
else
    echo "Repository already exists. Fetching latest changes..."
    cd /var/www/html/{{repo_name}}
    sudo git fetch --all
    echo "Resetting to the latest version of the main branch..."
    sudo git reset --hard origin/main
fi

# Set correct permissions
sudo chown -R www-data:www-data /var/www/html/{{repo_name}}/storage
sudo chown -R www-data:www-data /var/www/html/{{repo_name}}/bootstrap/cache
sudo chmod -R 775 /var/www/html/{{repo_name}}/storage
sudo chmod -R 775 /var/www/html/{{repo_name}}/bootstrap/cache

# Update Laravel environment file
if [-f "/var/www/html/{{repo_name}}/.env"]; then
    echo "Updating existing .env file..."
    # Update existing variables
    sudo sed -i "s|^APP_URL=.*|APP_URL={{domain}}|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_CONNECTION=.*|DB_CONNECTION=mysql|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_HOST=.*|DB_HOST=127.0.0.1|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_PORT=.*|DB_PORT=3306|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_DATABASE=.*|DB_DATABASE={{db_name}}|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_USERNAME=.*|DB_USERNAME={{db_user}}|" /var/www/html/{{repo_name}}/.env
    sudo sed -i "s|^DB_PASSWORD=.*|DB_PASSWORD={{db_pass}}|" /var/www/html/{{repo_name}}/.env
else
    echo "Creating new .env file..."
    cat <<EOL | sudo tee /var/www/html/{{repo_name}}/.env
APP_URL={{domain}}

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE={{db_name}}
DB_USERNAME={{db_user}}
DB_PASSWORD={{db_pass}}
EOL
fi

# Run Laravel setup commands
cd /var/www/html/{{repo_name}}
sudo php artisan key:generate
sudo php artisan migrate

# Configure Caddy
cat <<EOL | sudo tee /etc/caddy/Caddyfile
{{domain}} {
    root * /var/www/html/{{repo_name}}/public # Serve files from the Laravel public directory
    php_fastcgi unix//run/php-fpm/www.sock # Pass PHP requests to PHP-FPM
    file_server # Serve static files
}
EOL

# Start and enable Caddy
sudo systemctl start caddy
sudo systemctl enable caddy

# Install Firewall & Configure Rules
sudo dnf install -y firewalld
sudo systemctl start firewalld
sudo systemctl enable firewalld
sudo firewall-cmd --zone=public --permanent --add-service=http
sudo firewall-cmd --zone=public --permanent --add-service=https
sudo firewall-cmd --reload

echo "Laravel deployment and SSL setup complete!"

This is what the Laravel Deployment Script does:

Installs Git for repository cloning
Defines the GitHub repository and target directory
Clones the Laravel project or updates it if it already exists
Sets proper permissions for storage and cache directories
Runs Laravel migration and key generation to prepare the application
Deploy the application with Caddy

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{db_name}}, {{db_user}}, {{db_pass}}, {{github_access_token}}, {{github_user}}, {{repo_name}}, and {{domain}} used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

db_name: This is the name database for the Laravel application
db_user: Database user for the Laravel application
db_pass: Password for the database user
github_access_token: This is your GitHub personal access token for cloning the repository
github_user: This is your GitHub Username
repo_name: This is the name of the GitHub repository
domain: Domain name for the Laravel application e.g., myapp.com

Since the variables are setup, proceed to run the scripts with CloudRay.

Running the Script with CloudRay

Now that everything is setup, you can use CloudRay to automate the deployment of your Laravel Application

You can choose to run the scripts individually or execute them all at once using CloudRay’s Script Playlists. Since there are multiple scripts, using CloudRay playlists will help automate the execution sequence and save time.

Here are the steps to follow:

Navigate to “Script Playlists”: Click on the Scripts tab in the CloudRay interface
Click “Add Script Playlist”: This initiates the creation of a new playlist
Provide a Name: Give your playlist a unique name (For example “Automate Deployment and Management of Laravel Application”)
Add Scripts in Order: Select and add the scripts sequentially
Save the Playlist: Click “create playlist” to store your new playlist.

Once your script playlist is created, proceed with execution:

Navigate to Runlogs : In your CloudRay project, go to the Runlogs section in the top menu.
Create a New Runlog : Click on New Runlog
Configure the Runlog : Provide the necessary details:
Server: Select the server where your Laravel application will be installed
Script Playlist: Choose the playlist you created (For example “Automate Deployment and Management of Laravel Application”)
Variable Group: Select the variable group you set up earlier
Execute the Script : Click on Run Now to start the execution

Your Laravel Application is now seamlessly deployed and managed with CloudRay. That’s it! Happy deploying!. You can access it by visiting http://myapp.com

Troubleshooting

If you encounter issues during deployment, consider the following:

Caddy Fails to Start: Check the Caddy service status with sudo systemctl status caddy and restart it using sudo systemctl restart caddy
PHP-FPM Not Working: Ensure PHP-FPM is running with sudo systemctl status php-fpm and restart it using sudo systemctl restart php-fpm
SSL Certificate Not Issued: Verify your domain’s DNS records and ensure ports 80 and 443 are open in the firewall.
Laravel Application Not Loading: Check the .env file for correct database credentials and ensure the storage and bootstrap/cache directories have the correct permissions.
Database Connection Issues: Verify the database credentials in the .env file and ensure MariaDB is running with sudo systemctl status mariadb

If the issue persists, consult the Caddy Documentation or the Laravel Documentation for further assistance.

Related Guides

Get Started with CloudRay

Automate the Installation of Nagios Using CloudRay

rising_segun — Thu, 06 Mar 2025 00:00:00 +0000

Automating the installation of Nagios on Rocky Linux 9 ensures consistency, reduces errors, and saves time when setting up monitoring for your environment. CloudRay a powerful automation tool, enables seamless setup, deployment, and management of Nagios. By leveraging CloudRay, you can automate the setting up, configurations, and deployment of Nagios.

In this guide, you will learn how to automate the installation of Nagios Core on Rocky Linux 9 using CloudRay.

IMPORTANT

This article focuses on installing Nagios Core on Rocky Linux 9 using CloudRay. If you’re looking to monitor remote hosts using NRPE, check out our companion guide: How to Monitor Remote Hosts with Nagios Using CloudRay

Prerequisites
Assumptions
Create the Automation Script
- Setup Nagios Script
- Deploy Nagios Script
Create a Variable Group
Running the Scripts to Install Nagios with CloudRay
Troubleshooting

Prerequisites

Before getting started, make sure you have the following prerequisites in place:

A CloudRay account at https://app.cloudray.io/
A cloud server accessible via SSH: If you don’t already have a cloud server, you can get one from popular providers like AWS, DigitalOcean, and Google Cloud. Ensure the server has at least 4GB of RAM, and a minimum of 20GB SSD
SSH credentials: Ensure you have access to the necessary SSH keys or login credentials to access your server. If you don’t have an SSH key set up, follow this guide to create one and add it to CloudRay
The servers are added to CloudRay: Before proceeding, make sure your server is connected to CloudRay. If you haven’t done this yet, follow this guide to add and manage your server

NOTE

This guide uses Bash scripts, providing a high degree of customisation. You can adapt the scripts to fit your specific Installations needs and environment.

Assumptions

This guide assumes you’re using Rocky Linux 9 as your server’s operating system. If you’re using a different version or a different distribution, adjust the commands accordingly

Create the Automation Script

To automate the installation of Nagios, you’ll need two Bash scripts:

Setup Nagios Script: Installs the necessary dependencies and configures Nagios Core
Deploy Nagios Script: Sets up the web interface, enables Nagios, and configures the firewall

Let’s begin with the setting up of Nagios

Setup Nagios Script

To create the Setup Nagios Script, you need to follow these steps:

Go to Scripts in your CloudRay project
Click New Script
Name: Setup Nagios Script. You can give it any name of your choice
Copy this code:

#!/bin/bash

# Exit on error
set -e

# Update system packages
sudo dnf update -y

# Install required dependencies
sudo dnf install tar nano gcc glibc glibc-common wget perl net-snmp openssl-devel make unzip gd gd-devel epel-release httpd php php-cli php-common php-gd -y

# Create a directory for Nagios and navigate to it
cd ~
mkdir nagios
cd nagios

# Download Nagios Core
wget https://assets.nagios.com/downloads/nagioscore/releases/nagios-4.5.9.tar.gz

# Ensure tar is installed
sudo dnf install tar -y

# Extract Nagios
tar -xvf nagios-4.5.9.tar.gz
cd nagios-4.5.9

# Configure and compile Nagios
./configure
make all

# Create Nagios user and groups
sudo make install-groups-users
sudo usermod -a -G nagios apache

# Install Nagios and its components
sudo make install
sudo make install-init
sudo make install-commandmode
sudo make install-config
sudo make install-webconf

# Verify Nagios configuration
sudo /usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg

echo "Nagios core setup completed successfully!"

Here is a breakdown of what each command in the Setup Nagios Script does:

Updates all installed packages to the latest version
Installs essential packages like gcc, nano, wget, perl, httpd, and php
Creates and navigates to a directory for Nagios installation
Downloads Nagios Core (version 4.5.9 in this case) and Extracts the Nagios archive
Configures and compiles Nagios
Creates the nagios user and group and adds the apache user to the nagios group for web interface access
Install Nagios components, including the core configuration, init scripts, and web interface

Deploy Nagios Script

Next, you need to create the deployment script for Nagios. To do so, follow similar steps as the above:

Go to Scripts > New Script
Name: Deploy Nagios Script
Add code:

#!/bin/bash

# Exit on error
set -e

# Create Nagios admin user
sudo htpasswd -cb /usr/local/nagios/etc/htpasswd.users {{nagios_user}} {{nagios_password}}

# Set proper permissions
sudo chown apache:nagios /usr/local/nagios/etc/htpasswd.users

# Start and enable Nagios
sudo systemctl start nagios
sudo systemctl enable nagios

# Confirm Nagios is running
sudo systemctl status nagios --no-pager

# Install and configure FirewallD
sudo dnf install firewalld -y
sudo systemctl start firewalld
sudo systemctl enable firewalld

# Open HTTP port
sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

# Enable and restart services
sudo systemctl enable httpd
sudo systemctl restart nagios httpd

# Install Nagios plugins
cd ~/nagios/
wget https://nagios-plugins.org/download/nagios-plugins-2.4.11.tar.gz
tar -xvf nagios-plugins-2.4.11.tar.gz
cd nagios-plugins-2.4.11

./configure
make
sudo make install

# Final restart
sudo systemctl restart nagios httpd

echo "Nagios deployment completed successfully!"

This is what the Deploy Nagios Script does:

Creates a Nagios web admin user with the password
Ensures Apache and Nagios have the right permissions
Starts, enables, and checks the status of the Nagios service
Installs the firewall and opens port 80 for HTTP traffic
Downloads and installs Nagios plugins for additional monitoring capabilities
Restarts Nagios and the web server to apply changes

Create a Variable Group

Now, before running the scripts, you need to define values for the placeholders {{nagios-user}}, {{nagios-password}}, {{nagios-alias}}, {{nagios-email}}, {{nagios-server-ip}}, and {{remote-server-ip}} used in the scrips. CloudRay processes all scripts as Liquid templates. This allows you to use variables dynamically across different servers.

To ensure that these values are automatically substituted when the script runs, follow these steps to create a variable Group:

Navigate to Variable Groups: In your CloudRay project, go to “Scripts” in the top menu and click on “Variable Groups”.
Create a new Variable Group: Click on “Variable Group”.
Add the following variables:

nagios-user: This is the Nagios username
nagios-password: This is the Nagios password
nagios-alias: This is the Nagios alias
nagios-email: The email of the Nagios account
nagios-server-ip: The IP Address of the Nagios Server
remote-server-ip: The IP Address of the remote server to be monitored

Since the variables are setup, proceed to run the scripts with CloudRay.

Running the Scripts to Install Nagios with CloudRay

Now that everything is setup, you can use CloudRay to automate the installation of Nagios.

Here are the steps to follow:

Navigate to “Script Playlists”: Click on the Scripts tab in the CloudRay interface
Click “Add Script Playlist”: This initiates the creation of a new playlist
Provide a Name: Give your playlist a unique name (For example “Nagios Deployment Automation and Management”)
Add Scripts in Order: Select and add the scripts sequentially
Save the Playlist: Click “create playlist” to store your new playlist.

Once your script playlist is created, proceed with execution:

Navigate to Runlogs : In your CloudRay project, go to the Runlogs section in the top menu.
Create a New Runlog : Click on New Runlog.
Configure the Runlog : Provide the necessary details:
Server: Select the server where Nagios will be installed
Script Playlist: Choose the playlist you created (For example “Nagios Deployment Automation and Management”)
Variable Group: Select the variable group you set up earlier
Execute the Script : Click on Run Now to start the execution

Your Nagios is now seamlessly deployed and managed with CloudRay. That’s it! Happy deploying!. You can access it by visiting http://<nagios-server-ip>/nagios

Troubleshooting

If you encounter issues during deployment, consider the following:

Nagios Web Interface Not Loading: Ensure Apache is running with sudo systemctl status httpd and restart it using sudo systemctl restart httpd
Nagios Service Not Starting: Check the service status with sudo systemctl status nagios and restart it using sudo systemctl restart nagios

If the issue persists, consult the Nagios Core Documentation for further assistance.

Get Started with CloudRay

Best Way to Install Docker on Kali Linux

rising_segun — Wed, 29 Nov 2023 20:34:40 +0000

INTRODUCTION

Are you finding it difficult to install Docker on your Linux machine?
Docker is a powerful platform that enables developers to build, ship, and run applications in containers. Installing Docker on Kali can be tasking. Running docker Linux is a straightforward process, and in this guide, we'll walk you through each step, explaining the command line scripts along the way. Let's get started.

PREREQUISITES

Before installing docker. it is important to get have the following prerequisites:

A kali Linux Machine (ensure it is up-to-date)
Access to the terminal with sudo privileges
Basic understanding of command line.

To install docker in your kali linux machine, follow these steps:

Step 1: Update packages List

To start the installation of docker in your machine, it is important to update your package lists. To do this, open your terminal and run the following command to ensure that your package lists are updated:

sudo apt update

output:

Step 2: Install Docker

Once the package lists are successfully installed, install Docker using the following command:

sudo apt install docker.io

output:

Step 3: Enable and Start Docker Services

Docker requires a service to be running in the background. This steps enables and start the docker service with the following commands:

sudo systemctl enable docker --now

output:

This command not only enables Docker to start on boot but also starts the service immediately.

Step 4: Check Docker Service Status

To ensure docker is up and running, it is important to check the status. Use the following command:

sudo systemctl status docker

output:

This command provides detailed information about the Docker service, including its current status. Look for Active to confirm that Docker is running.

Step 5: Add Your User to the Docker Group

This step is required to avoid sudo each time you want to use Docker, add your user to the Docker group:

sudo usermod -aG docker $USER

This step grants your user the necessary permissions to interact with the Docker daemon.

Step 6: Restart Your System

To apply the changes made by adding your user to the Docker group, restart your system. You can do this by signing out and signing back in or using the command:

sudo reboot

Step 7: Verify Docker Installation

Confirm that Docker is successfully installed by checking its version:

docker --version

output:

This command displays the installed Docker version, confirming that the installation was successful.

CONCLUSION

Congratulations on successfully navigating through the installation of Docker on your Kali Linux machine! Docker brings a new level of flexibility and efficiency to your development and deployment workflows. With containers, you can ensure consistency across different environments, making your life as a developer much smoother. Feel free to explore Docker's vast capabilities and revolutionize the way you package and deploy applications.
Happy coding!

A Beginner's Guide: Installing MongoDB on Ubuntu 🔥 in 5 Simple Steps 🚀

rising_segun — Wed, 13 Sep 2023 21:04:28 +0000

Looking for a Hassle-Free MongoDB Installation on Ubuntu? Your search ends here! Follow this comprehensive step-by-step guide to effortlessly set up your MongoDB database on any Ubuntu or Linux-based system.

By the end of this article, you’ll have mastered installing MongoDB on Ubuntu effortlessly. This comprehensive guide not only offers a step-by-step walkthrough but also delves into the tools and techniques, providing valuable insights for seamless execution.

Prerequisites

To successfully install MongoDB on your Linux-based system, the following must be done:

knowledge of MongoDB
A general knowledge of working with command line/shell commands
Ubuntu or other Linux-based operating systems on the host workstation.

Steps to Install MongoDB on Ubuntu

MongoDB installation on Ubuntu is a simple process that allows you to set up a powerful and versatile NoSQL database on your system. By following a few simple steps, you can have MongoDB up and running in no time.

Step 1: Import MongoDB Repositories

It is important to ensure the legitimacy and integrity of the packages when installing MongoDB on Ubuntu. Ubuntu's Package Management system uses GPG keys to validate package signatures, adding an extra layer of security. To begin the MongoDB installation, you must first import the MongoDB Public GPG key into your Ubuntu system. The MongoDB Public GPG key can be imported with the following terminal command:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 7F0CEB10

Create a Source list for your MongoDB installation next. To accomplish this, use the following command to create the "/etc/apt/sources.list.d/mongodb-org-3.4.list" list file:

echo "deb http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list

With your list file now created, you can install the Local Package repository. To do this, you can use the following command:

sudo apt-get update

Step 2: Installing MongoDB Packages

You now need to install the latest stable version of MongoDB on your system. Use the below command:

sudo apt-get install -y mongodb

If you wish to install a certain version of MongoDB on your system, you must specify the version for each component package when you install it. For example, installing a specific version. run the following command:

sudo apt-get install -y mongodb-org=3.4 mongodb-org-server=3.4 mongodb-org-shell=3.4 mongodb-org-mongos=3.4 mongodb-org-tools=3.4

Step 3: Launching MongoDB as a Service on Ubuntu

Now that MongoDB is up and running, you must build a Unit file to assist your system in understanding the resource management process. For example, the most widely used Unit file determines how to start, stop, or manage a service automatically.
To do this, you can create a configuration file, “mongodb.service in /etc/systemd/system”, that will help manage the MongoDB system.

sudo vim /etc/systemd/system/mongodb.service

Next, copy the following information in your configuration file:

Now that the configuration file has been produced, use the following command to update the system service:

systemctl daemon-reload

Next, start the updated systemd service for your MongoDB instance:

sudo systemctl start mongodb

Once the instance is running, check to see if MongoDB launched on port 27017. To accomplish this, use the "netstat" command as follows:

netstat -plntu

To confirm if your MongoDB instance started successfully, you need to use the status command as:

sudo systemctl status mongodb

Now, you can now enable auto-start functionality for your system as follows:

sudo systemctl enable mongodb

For an instance you want to start or restart the MongoDB instance running on your Ubuntu installation, run the below commands:

sudo systemctl stop mongodb

sudo systemctl restart mongodb

Step 4: Configuring and Connecting MongoDB

From the above steps, we have successfully installed MongoDB service. This step shows how to install MongoDB. To do this, open the Mongo Shell and switch to the database admin mode using the following command:

mongo
use admin

Now, create a root user for your MongoDB installation and exit the Mongo Shell as follows:

db.createUser({user:"admin", pwd:”password", roles:[{role:"root", db:"admin"}]})

Note: you can replace the user and pwd with your preferred choice.

with this setup, you can now connect with your MongoDB, by first restarting MongoDB and then using the following command:

mongo -u admin -p admin123 --authenticationDatabase admin

you’ll now be able to see MongoDB set up a connection. You can use the “show dbs” command as follows to open a list of all available databases. With all these, you’ve successfully installed MongoDB on Ubuntu.

Step 5: MongoDB Tuning

Scaling MongoDB is simple and may be done horizontally or vertically. This is critical for the Database's optimal performance. Horizontal scaling involves the addition of server resources such as RAM and CPUs, whereas vertical scaling involves the addition of servers to the configuration. Several factors influence the performance of the MongoDB Database, including memory usage, the number of concurrent connections, and the WiredTiger Cache, among others. MongoDB's default storage engine is WiredTiger, which saves 50% of RAM. This indicates that 8GB of RAM will have a memory preserver of 0.5*(8-1) for WiredTiger. Use the following command to check use statistics and determine whether modifications are needed.

From the above result, some of the key points to note are listed below.

wiredTiger.cache.maximum bytes configure
wiredTiger.cache.bytes currently in the cache
wiredTiger.cache.pages read into cache
wiredTiger.cache.pages written from cache
wiredTiger.cache.tracked dirty bytes in the cache

To check the usage of WiredTiger Concurrency Read and Write Ticket, follow the command given below.

Conclusion

In just 5 straightforward steps, you've embarked on a journey to harness the power of MongoDB on your Ubuntu system. By following this beginner's guide, you've not only successfully installed MongoDB but also gained valuable insights into managing databases on Linux.
With MongoDB in your toolkit, you're well-equipped to handle diverse data needs and build robust applications. So, go ahead and explore the endless possibilities this NoSQL database offers. Whether you're a developer, a data enthusiast, or a tech enthusiast, MongoDB on Ubuntu is your gateway to efficient data management.
Start your MongoDB adventure today and witness your projects scale and thrive like never before!"