# Deploy Handbook — full published content > 39 articles. Source: https://deployhandbook.com --- ## Small self-hosters need a migration preflight before Vercel, colo, or VPS changes become scary Source: https://deployhandbook.com/blog/alternatives/vercel-colo-vps-migration-preflight Published: 2026-06-25 Tags: migration, vercel, vps, dns, self-hosting, alternatives, servercompass Fresh Reddit threads show two versions of the same deployment anxiety. A freelancer with a simple React/D3 portfolio and Vercel-managed domain wants to leave Vercel but is unsure how risky the provider and domain move will be. A self-hoster with a colocated… A self-hosted service usually looks healthy right up until the moment a real person depends on it. The web UI loads once, the container says it is running, the dashboard has a green row, and everyone moves on. The problem is that most failures in small infrastructure do not start at the happy-path install command. They start at the boundary between data, network, power, storage, credentials, clients, and the next change you make under pressure. Fresh Reddit threads show two versions of the same deployment anxiety. A freelancer with a simple React/D3 portfolio and Vercel-managed domain wants to leave Vercel but is unsure how risky the provider and domain move will be. A self-hoster with a colocated NUC running domain, email, web, SSH, and 1TB+ private storage needs a new home after the current host is shutting down. This can support a ServerCompass article on a low-risk migration checklist: inventory services and DNS, separate domain registrar from deploy target, test the new host behind a temporary hostname, plan mail and static IP needs, validate backups, and only then cut over That is the useful angle here: this is not another checklist for chasing a perfect homelab. It is a way to decide what must be true before you trust the service with real users, family data, client work, or a weekend migration. ## The pattern behind the failure kiwison is a non-web-dev freelancer with a low-traffic React/D3 portfolio and contact form on Vercel, with the domain also bought through Vercel, and is intimidated by moving to Railway or another provider. ParticularAd8610 is self-hosting domain, email, web, SSH, and private data on a colocated NUC but the hosting company is closing, forcing a VPS/colo decision with 1TB+ storage, static IP, and privacy requirements. The recurring pain is not app code; it is migration confidence, DNS/domain ownership, data location, backup verification, and cutover order. Read that as a systems problem rather than a collection of unrelated tool complaints. One person may be looking at a NAS, another at a proxy, another at a media library, and another at a small VPS, but the shape is the same. A visible setup step succeeded while an invisible dependency stayed unproven. That invisible dependency is where most self-hosted work becomes expensive. If you discover it during planning, it is a note in a runbook. If you discover it after a power cut, upgrade, certificate reload, or family movie night, it becomes an outage with incomplete evidence. The source signal came from several current operator threads: [thread 1](https://www.reddit.com/r/webdev/comments/1ue4a9g/scared_about_migrating_to_a_new_provider_can/), [thread 2](https://www.reddit.com/r/selfhosted/comments/1ue2a2c/colo_recommendations_and_or_vps/). ![Pi-hole deployment template inside ServerCompass while choosing an app deployment path](https://assets.stoicsoft.com/template-guides/servercompass/pihole/04-select-pihole-template.png) *Use screenshots like this as a reminder to plan the deployment path, not only the app name.* ## Start with the promise the service is making Before choosing the next app, OS, dashboard, tunnel, or VPS size, write one plain sentence: what does this service promise to keep working? A media server promises that people can find and play the library from the devices they actually use. A monitoring stack promises that an alert explains what changed, not just that a URL stopped answering. A migration promises that old data can be restored and the cutover can be reversed. A public web app promises that DNS, TLS, CORS, uploads, and background jobs all agree about the same production address. That sentence gives you the operating boundary. It tells you which checks matter and which impressive-looking tooling can wait. It also keeps the plan grounded when a thread, tutorial, or AI assistant starts suggesting a pile of extra components. For this topic, the relevant signals are `migration`, `vercel`, `vps`, `dns`, `self-hosting`. Treat those tags as dependencies to prove. They are not just SEO labels; they are the parts of the system most likely to make the difference between a service that starts and a service that can be trusted. ## The preflight map Use this sequence before the install, migration, upgrade, or hardware purchase becomes irreversible: - **External DNS answer:** `dig +short your-domain.example @1.1.1.1` should return the address the public internet will hit, not only the answer your LAN resolver gives you. - **TLS from outside the LAN:** `openssl s_client -connect your-domain.example:443 -servername your-domain.example </dev/null` should show the certificate chain the browser will actually receive. - **HTTP behavior at the app route:** `curl -Iv https://your-domain.example/health` should exercise the reverse proxy, the upstream app, redirects, headers, and auth boundary together. - **Preflight and callback paths:** For CORS, OAuth, webhooks, and Collabora-style integrations, test the exact public callback URL instead of assuming the base domain proves the app. - **Exposure inventory:** List every forwarded port, tunnel hostname, public admin page, and SSH path, then close anything that is not intentionally public. The point is not to turn every home server into enterprise process. The point is to make the next hour of work reversible. A short written preflight catches the assumption that would otherwise stay hidden until the service is live. ## What this looks like in practice | Area | Proof you want before trusting it | |---|---| | External DNS answer | dig +short your-domain.example @1.1.1.1 should return the address the public internet will hit, not only the answer your LAN resolver gives you. | | TLS from outside the LAN | openssl s_client -connect your-domain.example:443 -servername your-domain.example </dev/null should show the certificate chain the browser will actually receive. | | HTTP behavior at the app route | curl -Iv https://your-domain.example/health should exercise the reverse proxy, the upstream app, redirects, headers, and auth boundary together. | | Preflight and callback paths | For CORS, OAuth, webhooks, and Collabora-style integrations, test the exact public callback URL instead of assuming the base domain proves the app. | If one row in that table feels vague, that is the row to slow down on. Vague proof is usually a sign that the system is crossing a boundary: LAN to public internet, host filesystem to container mount, web UI to background worker, old disk to new pool, local client to remote client, or human memory to written runbook. A useful preflight does not need to be long. It needs to be specific enough that a second person, or your future self, can repeat it without guessing what you meant. For example, "check backups" is weak. "Restore one app database dump and one uploaded file into a temporary path, then open the app against it" is useful. "Domain works" is weak. "Curl the public route from outside the LAN, verify the certificate, and test the real callback path" is useful. ![ServerCompass showing a completed deployment dashboard after an app is running](https://assets.stoicsoft.com/template-guides/servercompass/pihole/08-deployment-success.png) *The deployment is only the first state to prove; the dashboard should lead into checks for data, access, rollback, and monitoring.* ## Keep the runbook small enough to use The best runbook for a small self-hosted service is usually one page. It should include the service purpose, the data locations, the update command, the backup location, the restore sample, the public URL or private access method, the expected health check, and the rollback stop point. Anything longer tends to become documentation theatre. Anything shorter tends to skip the part you will need during the incident. When the setup uses Docker Compose, keep the compose file, environment variables, and volume map together. When it uses a NAS or hypervisor, keep the storage ownership decision explicit. When it uses a reverse proxy, record which host terminates TLS and which app receives the upstream request. When it uses a tunnel or VPN, record whether the service is meant to be public, private, or split by route. This is also where product selection becomes less emotional. You can compare tools by whether they make the proof easier. A tool that gives you logs, restart history, a clear volume map, and a rollback path may be better for a small operator than a more flexible platform that hides those basics behind extra layers. ## Where ServerCompass fits [ServerCompass](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) is useful when the work is no longer just "install the app" and has become "keep the app deployable on a VPS." It gives you a repeatable place to choose templates, see what was deployed, and keep the operational surface visible enough to inspect. That does not replace backups, DNS checks, client testing, or a recovery plan. It gives those checks a clearer starting point. The practical move is to use a deployment tool for the repeatable part and keep the promise-specific proof in your own runbook. If this service matters, do not stop at a successful install screen. Prove the data path, prove the access path, prove the rollback path, and only then call it ready. ## Final checklist - Write the service promise in one sentence. - List the data, network, storage, and credential boundaries. - Run one outside-in access test and one inside-the-host health test. - Restore a small sample before the next major change. - Define the rollback trigger before you begin. - Keep screenshots, commands, and links close to the deployment record. That is enough structure for a small operator to move faster without turning every app into a platform project. More importantly, it turns vague confidence into evidence you can reuse the next time the same class of problem appears. --- ## Self-hosters want a simpler middle path before their containers turn into platform engineering Source: https://deployhandbook.com/blog/compare/docker-compose-middle-path-before-platform-engineering Published: 2026-06-25 Tags: self-hosting, docker-compose, complexity, vps, ops, compare, servercompass A fresh self-hosted thread asks what people cut back after their setups became too complex, while another documents a migration from one hardened Docker Compose VM into a TrueNAS-backed Nomad/Consul/Vault platform. Together they show the middle-market… A self-hosted service usually looks healthy right up until the moment a real person depends on it. The web UI loads once, the container says it is running, the dashboard has a green row, and everyone moves on. The problem is that most failures in small infrastructure do not start at the happy-path install command. They start at the boundary between data, network, power, storage, credentials, clients, and the next change you make under pressure. A fresh self-hosted thread asks what people cut back after their setups became too complex, while another documents a migration from one hardened Docker Compose VM into a TrueNAS-backed Nomad/Consul/Vault platform. Together they show the middle-market problem ServerCompass is built around: operators want better deployment state, logs, health checks, and rollback, but many do not actually want to own a scheduler, service mesh, or sprawling dashboard. This can become a ServerCompass article on auditing small stacks, cutting unnecessary services, and keeping Compose/VPS deployments maintainable before complexity becomes the hobby That is the useful angle here: this is not another checklist for chasing a perfect homelab. It is a way to decide what must be true before you trust the service with real users, family data, client work, or a weekend migration. ## The pattern behind the failure Belencutie asks whether others simplified after adding too many self-hosted services, containers, or tools that became hard to maintain. Silkkydev describes the other side of the curve: moving a public Redlib service from one carefully hardened Docker Compose VM behind Cloudflare, Traefik, and Anubis into a TrueNAS-backed Nomad/Consul/Vault platform. The common signal is that operators need a practical middle path: enough visibility and rollback to be safe, without platform-engineering overhead for a handful of apps. Read that as a systems problem rather than a collection of unrelated tool complaints. One person may be looking at a NAS, another at a proxy, another at a media library, and another at a small VPS, but the shape is the same. A visible setup step succeeded while an invisible dependency stayed unproven. That invisible dependency is where most self-hosted work becomes expensive. If you discover it during planning, it is a note in a runbook. If you discover it after a power cut, upgrade, certificate reload, or family movie night, it becomes an outage with incomplete evidence. The source signal came from several current operator threads: [thread 1](https://www.reddit.com/r/selfhosted/comments/1ue7ktd/overcomplicating_setups/), [thread 2](https://www.reddit.com/r/selfhosted/comments/1udf9bu/from_one_docker_compose_vm_to_a_truenasbacked/). ![Portainer deployment template inside ServerCompass while choosing an app deployment path](https://assets.stoicsoft.com/template-guides/servercompass/portainer/04-select-portainer-template.png) *Use screenshots like this as a reminder to plan the deployment path, not only the app name.* ## Start with the promise the service is making Before choosing the next app, OS, dashboard, tunnel, or VPS size, write one plain sentence: what does this service promise to keep working? A media server promises that people can find and play the library from the devices they actually use. A monitoring stack promises that an alert explains what changed, not just that a URL stopped answering. A migration promises that old data can be restored and the cutover can be reversed. A public web app promises that DNS, TLS, CORS, uploads, and background jobs all agree about the same production address. That sentence gives you the operating boundary. It tells you which checks matter and which impressive-looking tooling can wait. It also keeps the plan grounded when a thread, tutorial, or AI assistant starts suggesting a pile of extra components. For this topic, the relevant signals are `self-hosting`, `docker-compose`, `complexity`, `vps`, `ops`. Treat those tags as dependencies to prove. They are not just SEO labels; they are the parts of the system most likely to make the difference between a service that starts and a service that can be trusted. ## The preflight map Use this sequence before the install, migration, upgrade, or hardware purchase becomes irreversible: - **Data owner:** Write down which system owns the original files, which app owns metadata, and where exports or sidecars will live. - **Mount proof:** `docker compose exec app ls -la /media` or the equivalent VM check should show the same folders the app picker is expected to scan. - **Client proof:** Test the weakest real client, such as a Roku, mobile device, web player, or remote browser, before declaring the migration done. - **Rollback boundary:** Keep the previous app config, library database, and watch-state export until the new service has survived normal household use. - **Restore drill:** Restore a small folder, a database dump, and one app config file into a temporary path before trusting the backup policy. The point is not to turn every home server into enterprise process. The point is to make the next hour of work reversible. A short written preflight catches the assumption that would otherwise stay hidden until the service is live. ## What this looks like in practice | Area | Proof you want before trusting it | |---|---| | Data owner | Write down which system owns the original files, which app owns metadata, and where exports or sidecars will live. | | Mount proof | docker compose exec app ls -la /media or the equivalent VM check should show the same folders the app picker is expected to scan. | | Client proof | Test the weakest real client, such as a Roku, mobile device, web player, or remote browser, before declaring the migration done. | | Rollback boundary | Keep the previous app config, library database, and watch-state export until the new service has survived normal household use. | If one row in that table feels vague, that is the row to slow down on. Vague proof is usually a sign that the system is crossing a boundary: LAN to public internet, host filesystem to container mount, web UI to background worker, old disk to new pool, local client to remote client, or human memory to written runbook. A useful preflight does not need to be long. It needs to be specific enough that a second person, or your future self, can repeat it without guessing what you meant. For example, "check backups" is weak. "Restore one app database dump and one uploaded file into a temporary path, then open the app against it" is useful. "Domain works" is weak. "Curl the public route from outside the LAN, verify the certificate, and test the real callback path" is useful. ![ServerCompass showing a completed deployment dashboard after an app is running](https://assets.stoicsoft.com/template-guides/servercompass/portainer/08-deployment-success.png) *The deployment is only the first state to prove; the dashboard should lead into checks for data, access, rollback, and monitoring.* ## Keep the runbook small enough to use The best runbook for a small self-hosted service is usually one page. It should include the service purpose, the data locations, the update command, the backup location, the restore sample, the public URL or private access method, the expected health check, and the rollback stop point. Anything longer tends to become documentation theatre. Anything shorter tends to skip the part you will need during the incident. When the setup uses Docker Compose, keep the compose file, environment variables, and volume map together. When it uses a NAS or hypervisor, keep the storage ownership decision explicit. When it uses a reverse proxy, record which host terminates TLS and which app receives the upstream request. When it uses a tunnel or VPN, record whether the service is meant to be public, private, or split by route. This is also where product selection becomes less emotional. You can compare tools by whether they make the proof easier. A tool that gives you logs, restart history, a clear volume map, and a rollback path may be better for a small operator than a more flexible platform that hides those basics behind extra layers. ## Where ServerCompass fits [ServerCompass](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) is useful when the work is no longer just "install the app" and has become "keep the app deployable on a VPS." It gives you a repeatable place to choose templates, see what was deployed, and keep the operational surface visible enough to inspect. That does not replace backups, DNS checks, client testing, or a recovery plan. It gives those checks a clearer starting point. The practical move is to use a deployment tool for the repeatable part and keep the promise-specific proof in your own runbook. If this service matters, do not stop at a successful install screen. Prove the data path, prove the access path, prove the rollback path, and only then call it ready. ## Final checklist - Write the service promise in one sentence. - List the data, network, storage, and credential boundaries. - Run one outside-in access test and one inside-the-host health test. - Restore a small sample before the next major change. - Define the rollback trigger before you begin. - Keep screenshots, commands, and links close to the deployment record. That is enough structure for a small operator to move faster without turning every app into a platform project. More importantly, it turns vague confidence into evidence you can reuse the next time the same class of problem appears. --- ## Compose stack managers are outgrowing Portainer before they actually need Kubernetes Source: https://deployhandbook.com/blog/compare/portainer-komodo-kubernetes-compose-stack-managers Published: 2026-06-25 Tags: docker-compose, portainer, komodo, gitops, self-hosting, compare, servercompass Fresh self-hosted threads show operators stuck in the middle between a single Docker Compose VM and full platform engineering. One Portainer user is annoyed by git-cloned stack management and is evaluating Komodo, env repositories, TOML sync, and Ansible… A self-hosted service usually looks healthy right up until the moment a real person depends on it. The web UI loads once, the container says it is running, the dashboard has a green row, and everyone moves on. The problem is that most failures in small infrastructure do not start at the happy-path install command. They start at the boundary between data, network, power, storage, credentials, clients, and the next change you make under pressure. Fresh self-hosted threads show operators stuck in the middle between a single Docker Compose VM and full platform engineering. One Portainer user is annoyed by git-cloned stack management and is evaluating Komodo, env repositories, TOML sync, and Ansible redeploys. Another migrated a public service from a hardened Compose VM to a TrueNAS-backed Nomad/Consul/Vault platform. This supports a ServerCompass article on the practical middle path: keep Compose ergonomic, make git/env handling explicit, add logs/health/rollback, and avoid adopting an entire scheduler stack just to manage a handful of VPS or homelab services That is the useful angle here: this is not another checklist for chasing a perfect homelab. It is a way to decide what must be true before you trust the service with real users, family data, client work, or a weekend migration. ## The pattern behind the failure Kengurugames uses Portainer for a homelab but dislikes managing stacks cloned from git and is evaluating Komodo with repo branching, per-host env repos, TOML sync, and Ansible redeploys. Silkkydev describes moving from a public Redlib service on one Docker Compose VM behind Cloudflare/Traefik/Anubis into a TrueNAS-backed Nomad/Consul/Vault community-services platform. The recurring buyer problem is not whether containers work; it is deploy ergonomics, git/env state, health visibility, and rollback before Kubernetes-scale complexity is justified. Read that as a systems problem rather than a collection of unrelated tool complaints. One person may be looking at a NAS, another at a proxy, another at a media library, and another at a small VPS, but the shape is the same. A visible setup step succeeded while an invisible dependency stayed unproven. That invisible dependency is where most self-hosted work becomes expensive. If you discover it during planning, it is a note in a runbook. If you discover it after a power cut, upgrade, certificate reload, or family movie night, it becomes an outage with incomplete evidence. The source signal came from several current operator threads: [thread 1](https://www.reddit.com/r/selfhosted/comments/1udurmb/how_are_you_using_komodo/), [thread 2](https://www.reddit.com/r/selfhosted/comments/1udf9bu/from_one_docker_compose_vm_to_a_truenasbacked/). ![Portainer deployment template inside ServerCompass while choosing an app deployment path](https://assets.stoicsoft.com/template-guides/servercompass/portainer/04-select-portainer-template.png) *Use screenshots like this as a reminder to plan the deployment path, not only the app name.* ## Start with the promise the service is making Before choosing the next app, OS, dashboard, tunnel, or VPS size, write one plain sentence: what does this service promise to keep working? A media server promises that people can find and play the library from the devices they actually use. A monitoring stack promises that an alert explains what changed, not just that a URL stopped answering. A migration promises that old data can be restored and the cutover can be reversed. A public web app promises that DNS, TLS, CORS, uploads, and background jobs all agree about the same production address. That sentence gives you the operating boundary. It tells you which checks matter and which impressive-looking tooling can wait. It also keeps the plan grounded when a thread, tutorial, or AI assistant starts suggesting a pile of extra components. For this topic, the relevant signals are `docker-compose`, `portainer`, `komodo`, `gitops`, `self-hosting`. Treat those tags as dependencies to prove. They are not just SEO labels; they are the parts of the system most likely to make the difference between a service that starts and a service that can be trusted. ## The preflight map Use this sequence before the install, migration, upgrade, or hardware purchase becomes irreversible: - **Owner:** Name the system that owns the data, configuration, network path, and rollback decision. - **Proof:** Test the exact path users will rely on, not only the setup screen that says the service started. - **Backup:** Restore one realistic sample before changing the production service. - **Monitoring:** Record the signal that will tell you whether the service is healthy tomorrow. - **Rollback:** Write the stopping condition before the maintenance window starts. The point is not to turn every home server into enterprise process. The point is to make the next hour of work reversible. A short written preflight catches the assumption that would otherwise stay hidden until the service is live. ## What this looks like in practice | Area | Proof you want before trusting it | |---|---| | Owner | Name the system that owns the data, configuration, network path, and rollback decision. | | Proof | Test the exact path users will rely on, not only the setup screen that says the service started. | | Backup | Restore one realistic sample before changing the production service. | | Monitoring | Record the signal that will tell you whether the service is healthy tomorrow. | If one row in that table feels vague, that is the row to slow down on. Vague proof is usually a sign that the system is crossing a boundary: LAN to public internet, host filesystem to container mount, web UI to background worker, old disk to new pool, local client to remote client, or human memory to written runbook. A useful preflight does not need to be long. It needs to be specific enough that a second person, or your future self, can repeat it without guessing what you meant. For example, "check backups" is weak. "Restore one app database dump and one uploaded file into a temporary path, then open the app against it" is useful. "Domain works" is weak. "Curl the public route from outside the LAN, verify the certificate, and test the real callback path" is useful. ![ServerCompass showing a completed deployment dashboard after an app is running](https://assets.stoicsoft.com/template-guides/servercompass/portainer/08-deployment-success.png) *The deployment is only the first state to prove; the dashboard should lead into checks for data, access, rollback, and monitoring.* ## Keep the runbook small enough to use The best runbook for a small self-hosted service is usually one page. It should include the service purpose, the data locations, the update command, the backup location, the restore sample, the public URL or private access method, the expected health check, and the rollback stop point. Anything longer tends to become documentation theatre. Anything shorter tends to skip the part you will need during the incident. When the setup uses Docker Compose, keep the compose file, environment variables, and volume map together. When it uses a NAS or hypervisor, keep the storage ownership decision explicit. When it uses a reverse proxy, record which host terminates TLS and which app receives the upstream request. When it uses a tunnel or VPN, record whether the service is meant to be public, private, or split by route. This is also where product selection becomes less emotional. You can compare tools by whether they make the proof easier. A tool that gives you logs, restart history, a clear volume map, and a rollback path may be better for a small operator than a more flexible platform that hides those basics behind extra layers. ## Where ServerCompass fits [ServerCompass](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) is useful when the work is no longer just "install the app" and has become "keep the app deployable on a VPS." It gives you a repeatable place to choose templates, see what was deployed, and keep the operational surface visible enough to inspect. That does not replace backups, DNS checks, client testing, or a recovery plan. It gives those checks a clearer starting point. The practical move is to use a deployment tool for the repeatable part and keep the promise-specific proof in your own runbook. If this service matters, do not stop at a successful install screen. Prove the data path, prove the access path, prove the rollback path, and only then call it ready. ## Final checklist - Write the service promise in one sentence. - List the data, network, storage, and credential boundaries. - Run one outside-in access test and one inside-the-host health test. - Restore a small sample before the next major change. - Define the rollback trigger before you begin. - Keep screenshots, commands, and links close to the deployment record. That is enough structure for a small operator to move faster without turning every app into a platform project. More importantly, it turns vague confidence into evidence you can reuse the next time the same class of problem appears. --- ## Push, Bind a Domain, See Logs: Self-Hosted PaaS Without the YAML Sprawl Source: https://deployhandbook.com/blog/best/self-hosted-paas-push-to-deploy-without-yaml Published: 2026-06-23 Tags: paas, vercel-alternative, coolify, dokploy, deployment CapRover, Coolify, Dokploy, or raw VPS? Self-hosters want the Vercel workflow — push code, bind a domain or tunnel, see logs — without hand-maintaining YAML. How the options actually compare. Self-hosters shopping for a "Vercel I can run myself" all describe the same wish list: push code, bind a domain (or a tunnel if you're behind CGNAT), see logs and resource usage, and — above all — *not* hand-maintain a sprawl of YAML. The market answer is a handful of self-hosted PaaS tools (CapRover, Coolify, Dokploy) plus the always-available raw VPS. They're not interchangeable. Here's how they compare on the workflow people actually care about. ## Judge them on the workflow, not the feature matrix Every tool lists a hundred features. For "Vercel on my VPS," only a few matter: - **Git push → deploy** without writing a pipeline by hand. - **Domain/TLS binding** in a couple of clicks (and a tunnel option for [CGNAT](https://deploytovps.com/guide/cgnat-clean-domain-access-without-exposing-443)). - **Logs and resource usage** visible without SSH. - **Low YAML** — config generated for you, not authored. ## The options **CapRover.** The most "appliance-like." Captain definitions and one-click apps; push via its CLI or Git. Mature and simple; less flashy, very low-YAML for common cases. **Coolify.** The current darling — slick UI, Git integration, databases, previews, and a large app catalog. Most Vercel-like experience; actively developed. A bit heavier. **Dokploy.** Newer, clean, Docker/Compose-friendly with a good UI. A strong middle ground; Compose-native if you still want *some* declarative control. **Raw VPS + reverse proxy.** Maximum control, zero abstraction — you wire Traefik/Caddy and deploys yourself. Choose this only if you specifically want to own every layer; it's the [PaaS-to-VPS trade you're usually trying to avoid](https://deploytovps.com/guide/paas-to-vps-migration-checklist-what-vercel-railway-handled-for-you). ## Quick comparison | | Push-to-deploy | Domain + tunnel | Logs/metrics UI | YAML burden | Best when | |---|---|---|---|---|---| | CapRover | Yes | Yes / via add-ons | Basic | Very low | Simple, appliance-like | | Coolify | Yes | Yes | Good | Low | Most Vercel-like | | Dokploy | Yes | Yes | Good | Low–Med | Compose-friendly middle | | Raw VPS | DIY | DIY | DIY | High | You want full control | ## The decisions that actually pick the tool - **Want the closest thing to Vercel?** Coolify. - **Want the simplest, most appliance-y?** CapRover. - **Comfortable with Compose but want a UI on top?** Dokploy. - **Want to own every layer (and accept the work)?** Raw VPS. Whichever you pick, the [tunnel-vs-public-domain decision](https://deploytovps.com/guide/cgnat-clean-domain-access-without-exposing-443) and a [backup you've actually restored](https://deploytovps.com/guide/docker-volume-restore-drill) still apply — the PaaS handles deploys, not your data safety. ![ServerCompass dashboard showing one-click app deploys and status](https://assets.stoicsoft.com/template-guides/servercompass/immich/08-deployment-success.png) *A push-to-deploy workflow in [ServerCompass](https://servercompass.app) — deploy from a template or repo, bind a domain, and watch status without hand-writing YAML.* ## Takeaway The self-hosted PaaS choice isn't about feature counts — it's about which tool gives you push-to-deploy, easy domains/tunnels, and visible logs with the least YAML. Coolify for the most Vercel-like feel, CapRover for appliance simplicity, Dokploy for a Compose-friendly middle, raw VPS only if you want to own it all. Pick for the workflow; the rest is noise. --- ## Lighter Than Kubernetes: Compose vs Podman vs K8s for a Single-Node Homelab Source: https://deployhandbook.com/blog/compare/lightweight-orchestration-vs-kubernetes-single-node Published: 2026-06-23 Tags: kubernetes, podman, docker-compose, orchestration, homelab You want more structure than loose docker run commands but suspect Kubernetes is overkill for one Proxmox box. A practical comparison of Compose, rootless Podman, Podman Kube, and lightweight K8s. There's a stage every self-hoster reaches: loose `docker run` commands and a folder of half-remembered flags stop feeling like "structure," but spinning up Kubernetes on a single Proxmox box feels like bringing a container ship to cross a pond. The good news is the choice isn't binary. Between "chaos" and "full K8s" there's a spectrum — Compose, rootless Podman, Podman's Kube play, and lightweight Kubernetes — and for a single node the right pick is usually well short of the deep end. ## What you're actually trying to buy Before comparing tools, name the goal. "More structure" on one box usually means: declarative config you can version, automatic restarts, clean dependency/ordering, and a path that doesn't trap you. It rarely means multi-node scheduling, self-healing across machines, or rolling fleet deploys — the things Kubernetes is *for*. Match the tool to the goal, not to the hype. ## The options, lightest to heaviest **Docker Compose.** Declarative YAML, versionable, restart policies, dependency ordering. For a single node, this is "structured enough" for the vast majority of homelabs. It's the [reproducible-stack baseline](https://deploytovps.com/guide/vps-rebuild-automation-compose-traefik-mail), and most self-hosters never need more. **Rootless Podman.** Daemonless and rootless by default — a security win over the Docker socket (no [root-equivalent control socket](https://deploytovps.com/guide/docker-socket-safe-management-boundaries) to protect). Drop-in-ish for Docker workflows, with systemd integration for restarts. **Podman Kube play.** The clever middle: write Kubernetes-style YAML and run it locally with `podman kube play`. You get K8s-shaped manifests and a gentle on-ramp to Kubernetes concepts *without* running a cluster — ideal if you might go to K8s later and want to learn the syntax now. **Lightweight Kubernetes (k3s).** A small, single-binary K8s. Genuinely runnable on one node, and worth it *if* you specifically want the Kubernetes ecosystem (Helm charts, operators, the API). But you're now operating a control plane — etcd, the scheduler, networking — for one box. ## Quick comparison | | Structure | Learning curve | Overhead on one box | Best when | |---|---|---|---|---| | Compose | Good | Low | Minimal | Most single-node homelabs | | Rootless Podman | Good | Low–Med | Minimal | You want daemonless/rootless security | | Podman Kube play | High (K8s YAML) | Medium | Low | Learning K8s syntax without a cluster | | k3s | Highest | High | Real (control plane) | You specifically want the K8s ecosystem | ## How to choose - **Just want versionable, restarting, ordered services?** Compose. Stop here unless you have a concrete reason not to. - **Care about rootless/daemonless security?** Rootless Podman. - **Planning to learn or move to Kubernetes?** Podman Kube play now, k3s when you actually need the ecosystem. - **Genuinely want Helm/operators/the K8s API on one box?** k3s — eyes open about running a control plane. The trap is choosing k3s for *structure* when Compose would have given you 90% of it with 10% of the operational weight. The related question of [PaaS panels vs lightweight deploy tools](https://deployhandbook.com/compare/proxmox-panels-vs-lightweight-deploy-tools) is the same instinct from another angle. ## Whatever you pick, keep the box healthy Orchestration doesn't replace the basics: [sane health checks](https://deploytovps.com/guide/docker-health-checks-sane-defaults-for-self-hosted-services), backups you've restored, and resource limits so one workload can't starve the node. ## Takeaway On a single node, "lighter than Kubernetes" is almost always the right answer — and usually it's Compose or Podman, not a cluster. Buy the structure you actually need: declarative config and restarts for most, rootless Podman for security, Podman Kube play to learn K8s gently, and k3s only when you genuinely want the Kubernetes ecosystem. Don't run a control plane to organize one box. --- ## Hosted vs Self-Hosted Nextcloud for Small Teams: The Hidden Ops Costs Decide It Source: https://deployhandbook.com/blog/compare/hosted-vs-self-hosted-nextcloud-small-teams Published: 2026-06-22 Tags: nextcloud, hosted, self-hosted, comparison, small-teams Managed Nextcloud's monthly fee looks expensive next to a $10 VPS — until you price the ops the host quietly does for you. A real hosted-vs-self-hosted comparison for small teams. For a small team, the Nextcloud decision looks lopsided on paper: a managed provider wants a monthly fee per user, while a $10 VPS could run the same Nextcloud for everyone. Obvious, right? Self-host and save. The reason that math misleads is that the VPS price buys the *software running*, not the *operations* — and for Nextcloud specifically, the operations are exactly where the hidden cost lives. Here's the honest comparison. ## The sticker prices (and why they mislead) - **Hosted Nextcloud:** a clear monthly fee, often per-user. Includes backups, upgrades, uptime, and support — bundled, so you don't see them as line items. - **Self-hosted:** a small flat VPS bill. Includes *nothing else*. The other costs are real; they're just paid in your time instead of dollars. Comparing the two sticker prices compares a complete service to a bare server. Price the gap. ## The hidden ops costs of self-hosting Nextcloud Nextcloud is more operationally demanding than most apps its size — these are the costs the managed fee absorbs: - **Backups that actually restore.** DB + data + config, consistent, tested — not a folder copy ([why that matters](https://deploytovps.com/guide/migrate-immich-nextcloud-data-without-breaking-app-state)). - **Upgrades.** Nextcloud upgrades are frequent and occasionally bumpy; each needs a [backup-and-rollback preflight](https://deploytovps.com/guide/family-self-host-backup-rollback-before-upgrades). - **Performance tuning.** Preview generation, background cron, and PHP tuning — the [production preflights](https://deploytovps.com/guide/nextcloud-production-preflight-cpu-backups-smtp) that keep it from choking. - **Email.** Working SMTP with proper [domain DNS](https://deploytovps.com/guide/mail-server-domain-prerequisites) so shares and resets deliver. - **On-call.** When it breaks, *you* fix it — the [bus-factor cost](https://deploytovps.com/guide/self-host-runbooks-bus-factor-oncall) is real for a team that depends on it. ## A fairer comparison | Factor | Hosted | Self-hosted on a VPS | |---|---|---| | Monthly $ | Higher, per-user | Lower, flat | | Backups/upgrades | Included | Your time | | Performance tuning | Done for you | Your time | | Control & data ownership | Limited | Full | | Customization / apps | Provider-limited | Unlimited | | On-call | Provider | You | ## How small teams should actually decide - **Self-host when** someone on the team genuinely enjoys (or is paid for) ops, data control/customization matters, and the per-user hosted fee × your headcount clearly exceeds a VPS + a few hours a month. - **Stay hosted when** nobody wants to be on-call, the team is small enough that per-user pricing is cheap, or downtime is costlier than the subscription. - **Hybrid:** self-host on a VPS but make the ops cheap — deploy from a managed template so backups, TLS, and upgrades are handled rather than hand-built. ![ServerCompass VPS launch preflight checklist for DNS and SSL](https://assets.stoicsoft.com/posts/servercompass/vps-launch-preflight-checklist-dns-ssl.png) *Self-hosting Nextcloud sanely starts with a launch preflight in [ServerCompass](https://servercompass.app) — DNS, SSL, and backups set up front, which is where the hidden ops cost actually goes.* ## Takeaway The hosted-vs-self-hosted Nextcloud choice isn't decided by the two prices on the pricing pages — it's decided by the ops the prices hide. Self-hosting genuinely saves money for a team willing to own backups, upgrades, tuning, and on-call; for a team that isn't, the managed fee is buying back exactly those hours. Add the hidden costs to both columns, then the right answer is obvious for *your* team. --- ## EU-Based Cloudflare Alternatives: Reverse Proxy, SSL Termination, and No-Ingress Edge Security Source: https://deployhandbook.com/blog/alternatives/eu-cloudflare-alternatives-reverse-proxy-ssl Published: 2026-06-22 Tags: cloudflare-alternative, reverse-proxy, ssl, eu, security EU teams asking for a Cloudflare alternative usually want edge security under EU jurisdiction. A grouped comparison of EU CDNs, self-hosted EU edges, and no-ingress tunnels — and how to choose. "Is there a Cloudflare alternative based in the EU?" shows up on r/devops more and more, and the framing is consistent: teams want **edge security as a service** — reverse proxy, SSL termination, and *no ingress to the origin* — but provided by a vendor whose data handling sits under EU jurisdiction. The driver is data residency and vendor location, not a feature checklist. Cloudflare's feature set is rarely the complaint; *where* the traffic is decrypted and *who* processes it is. This is a comparison of the realistic options for EU-based or EU-constrained teams, grouped by how they actually work, plus how to choose between them. ## What "edge security as a service" actually means When people say "like Cloudflare," they usually want some subset of: - **Reverse proxy / TLS termination** at the edge, so the origin isn't directly addressable. - **No ingress to the server** — the origin makes outbound connections or sits behind the proxy; no public ports open on it. - **DDoS absorption and a WAF** in front of the app. - **A clean domain with managed certificates.** The catch that matters for EU teams: TLS termination means the edge *decrypts your traffic*. So "EU alternative" really means "an edge operator I'm comfortable decrypting and processing my traffic under EU rules." Keep that lens on every option below. ## Option A — EU edge/CDN vendors There are European CDN and edge-security providers that offer reverse proxying, TLS termination, and DDoS/WAF features comparable in shape to Cloudflare's. Examples that come up include Gcore, Bunny.net, and other regional CDNs. - **Pros:** Managed edge, DDoS scale you can't easily self-host, EU corporate domicile. - **Watch-outs:** Corporate location is **not** the same as a data-residency guarantee. PoPs are global by design, and a "European company" may still process or cache traffic outside the EU. Before committing, read the current DPA, confirm which regions terminate TLS and cache content, and check sub-processor lists. These terms change — verify them yourself rather than trusting a blog (including this one). ## Option B — Self-host the edge on an EU VPS (most control) Rent a VPS in an EU region from a provider you trust (Hetzner, Scaleway, OVHcloud, and similar) and run your own edge: **Caddy, Traefik, or nginx** for reverse proxy and automatic TLS, plus a WAF layer such as ModSecurity/Coraza or a managed-rules add-on. - **Pros:** You pick the exact country and provider; you control where TLS terminates and what's logged; no third party decrypts your traffic. Pairs naturally with the no-ingress pattern below. - **Watch-outs:** You own patching, certificate renewal, and capacity. DDoS resilience is limited to what your VPS and provider can absorb — fine for most small-team traffic, not a substitute for a large scrubbing network under a volumetric attack. This is usually the right default when **data residency is the hard requirement** and your DDoS exposure is modest. ## Option C — No-ingress tunnel models The "no ingress to the server" requirement can be satisfied directly with an outbound-tunnel architecture: the origin opens an outbound connection to an edge node, and nothing inbound is exposed. - **Self-hosted tunnels** — `frp`, `rathole`, or a WireGuard link to an EU VPS that runs the public-facing reverse proxy. Fully under your control and EU-located if the VPS is. - **Tailscale Funnel / WireGuard relays** — expose a specific service through a private overlay terminating on infrastructure you choose. - **Cloudflare Tunnel** delivers the no-ingress shape too, but it's still Cloudflare at the edge — so it answers the "no open ports" goal, not the "EU vendor" goal. No-ingress models are excellent for keeping origins dark, and when the edge node is your own EU VPS, you get residency control as a bonus. ## Quick comparison | Approach | Reverse proxy + TLS | No ingress to origin | DDoS scale | EU residency control | Ops effort | |---|---|---|---|---|---| | EU edge/CDN vendor (A) | Yes | Yes | High | Medium — verify DPA/PoPs | Low | | Self-hosted edge on EU VPS (B) | Yes | With tunnel | Low–Medium | High | High | | No-ingress tunnel to EU VPS (C) | Yes (on your VPS) | Yes | Low–Medium | High | Medium | | Cloudflare Tunnel | Yes | Yes | High | Low (US vendor) | Low | ## How to choose - **Residency is non-negotiable (GDPR-sensitive data, public-sector, contractual):** Self-host the edge on an EU VPS (B), optionally fronted by a no-ingress tunnel (C). You control the jurisdiction end to end. - **You need real DDoS scale and can accept a vetted EU vendor:** An EU edge/CDN (A) — but get the data-processing terms in writing and confirm where TLS terminates. - **The priority is "no open ports," not vendor location:** Any no-ingress model (C), including Cloudflare Tunnel if EU domicile isn't a hard requirement. - **Small team, modest traffic, wants control:** B is the most honest fit and the cheapest to reason about. ## Caveats worth repeating - **Vendor location ≠ data residency.** An EU-headquartered provider can still process traffic globally. The DPA and region settings are what matter, not the address on the website. - **TLS termination is a trust decision.** Whoever terminates your TLS sees your plaintext. If that must be inside the EU and under your control, you're pushed toward self-hosting the edge. - **Terms drift.** Pricing, regions, and sub-processors change. Treat any specific vendor claim — here or anywhere — as a starting point to verify against current documentation. ## The takeaway For EU teams, the "Cloudflare alternative" question is really a residency-and-trust question wearing a feature costume. If you need guaranteed EU handling, self-hosting the edge on an EU VPS — optionally behind a no-ingress tunnel — gives you the reverse proxy, SSL termination, and dark-origin properties you wanted, in a jurisdiction you choose. If you need large-scale DDoS protection and can vet a vendor's data-processing terms, a European edge/CDN fills that gap. Either way, decide based on where your traffic is decrypted and who processes it — that's the part the original question is really about. --- ## When Coolify API Limits Become a Team Provisioning Problem Source: https://deployhandbook.com/blog/alternatives/coolify-api-team-provisioning Published: 2026-06-05 Tags: coolify, api, team-management, provisioning, alternatives, self-hosted-paas Coolify is a strong self-hosted PaaS, but teams that need API-first project, team, and container provisioning should evaluate the workflow before standardizing on it. Coolify is a good answer for many teams that want a self-hosted PaaS. It gives you a dashboard, Git deployments, app templates, databases, SSL, and enough platform behavior to move off hosted PaaS bills without building everything from scratch. The question changes when your deployment workflow becomes API-first. If you need to create teams, projects, services, environments, secrets, and containers programmatically, a dashboard-first platform can become a bottleneck. The issue is not whether Coolify can deploy apps. It can. The issue is whether it can be the provisioning substrate for a repeatable multi-project workflow. That is a different bar. ## The dashboard workflow is not the API workflow Many small teams start with a dashboard because it is faster. A founder connects a Git repo, fills environment variables, picks a domain, and deploys. For one app, that is great. The workflow gets more demanding when you have: - multiple client projects - one environment per preview branch - new apps created from templates - repeatable staging and production setup - per-team permissions - automated secret injection - service creation from an internal portal - audit requirements around who provisioned what At that point, you are no longer asking for "a nice deploy UI." You are asking for infrastructure that can be driven by code. The difference matters because a missing API operation becomes a manual step. One manual step becomes a checklist. A checklist becomes drift. Drift becomes the reason staging no longer matches production. ## What to check before choosing Coolify for team provisioning Before standardizing on any self-hosted PaaS, write down the exact lifecycle you need to automate. For each new app, do you need an API to: - create a project - create or assign a team - set permissions - connect a Git repository - create an application service - attach a database - set environment variables and secrets - assign a domain - configure health checks - trigger the first deploy - read deploy status - fetch logs - roll back to a previous deploy - delete the whole environment Then check which of those operations are available, stable, documented, and safe to call repeatedly. The last phrase matters. An endpoint that works once from a script is not the same as an idempotent provisioning API. If your automation retries after a timeout, will it create duplicates? If a secret update fails halfway through, can you detect and repair the partial state? If a project already exists, can your script converge it to the desired configuration? Those are boring questions. They are also the questions that separate a dashboard tool from a platform primitive. ## When API gaps actually hurt API gaps are tolerable when the platform is operated by one person and changes are infrequent. They hurt when the workflow needs scale or repeatability. Common pain points: **Client onboarding.** An agency wants every new client to get the same app, database, domain pattern, staging environment, backup policy, and access rules. If three of those steps require clicking through a dashboard, onboarding speed depends on memory. **Preview environments.** A team wants each pull request to create a short-lived environment. That requires project creation, environment variables, domains or preview URLs, deploy triggers, and cleanup. Manual setup defeats the point. **Internal developer platforms.** A company wants developers to request a service through an internal portal. The portal needs API control over infrastructure. A dashboard-only action becomes a support ticket. **Multi-tenant SaaS operations.** A product team wants to provision isolated containers or stacks for tenants. This needs strict automation, retries, deletion, and auditability. **Compliance and audit.** If production changes need review, the provisioning source should be versioned. Clicking through a dashboard is harder to review than a pull request that changes a manifest. In those cases, the API is not a convenience. It is the control plane. ## Your options if Coolify is otherwise a good fit You do not have to abandon Coolify immediately because an API is missing. Choose the least dramatic path that fits the risk. ### Option 1: Keep Coolify for long-lived apps If your apps are stable and you only provision a few new services per month, keep Coolify as the deployment surface and document the manual steps. This is reasonable for founder-led stacks, homelabs, and small internal tools. Make the checklist explicit: - create project - connect repo - add secrets - attach domain - deploy - run health check - record ownership The danger is pretending the checklist is automation. ### Option 2: Use code for the pieces around Coolify Sometimes the missing API operations are not the core deployment. You may be able to automate DNS, secret generation, database backups, and health checks outside Coolify while leaving the app deploy in Coolify. This hybrid model works when the manual Coolify steps are rare and the high-risk operations are automated elsewhere. ### Option 3: Standardize on Docker Compose plus your own scripts If repeatability matters more than dashboard convenience, plain Docker Compose can be easier to automate. You lose the polished UI, but you gain explicit files and idempotent scripts. A simple stack can be driven by: - a Compose template - an env file generator - Caddy or Traefik labels - a deploy script - a backup script - a health check script This is not as friendly for casual users. It is often better for teams that need predictable provisioning. ### Option 4: Evaluate a workflow-first deployment tool Some teams do not need a full self-hosted PaaS. They need a repeatable deployment workflow that targets their VPS, keeps overhead low, and makes rollback explicit. In that model, the platform does not own every project. The workflow owns the deploy path. This is where tools like ServerCompass belong in the comparison. The question is not "does it have the biggest template catalog?" The question is "can my team run the same deploy safely every time?" ## Decision table | Need | Coolify fit | Watch out for | |---|---:|---| | One founder deploying a few apps | Strong | Keep backups and rollback tested | | Homelab or personal services | Strong | Do not over-automate too early | | Agency provisioning many client stacks | Mixed | Manual project setup becomes drift | | Preview environments per pull request | Weak unless API covers the lifecycle | Cleanup, domains, secrets, retries | | Internal platform portal | Mixed to weak | API completeness and idempotency | | Template catalog for common apps | Strong | Template success is not ops readiness | | GitOps-style infrastructure review | Mixed | Dashboard changes are harder to review | ## The practical evaluation script Before committing to any platform, run one realistic exercise: 1. Create a new project from scratch. 2. Add staging and production. 3. Set secrets. 4. Attach a database. 5. Deploy. 6. Fetch deploy status. 7. Fetch logs. 8. Roll back. 9. Delete the environment. 10. Repeat the whole flow from a script. If step 10 is impossible, decide whether that is acceptable for your team. For many small teams, it is acceptable. Coolify still gives them more than enough value. For teams building repeatable provisioning, it is a warning that they need a different control model or a hybrid architecture. ## The bottom line Coolify is strongest when a human operator wants a capable self-hosted PaaS dashboard. It is weaker when the deployment platform needs to be driven like infrastructure code. That does not make Coolify the wrong choice. It makes the choice more specific. If you need templates, a dashboard, and fast app setup, Coolify belongs on the shortlist. If you need programmatic team, project, and container provisioning, test the API lifecycle before you standardize. The cost of discovering the gap later is not just a missing endpoint. It is a workflow that quietly turns back into manual operations. --- ## How to compare GPU VPS providers without getting fooled by the cheapest hourly price Source: https://deployhandbook.com/blog/best/gpu-vps-comparison-without-being-fooled-by-cheap-hourly Published: 2026-06-03 Tags: gpu-vps, pricing, vram, self-hosting, provider-comparison GPU VPS shoppers reach for the cheapest hourly rate and then discover the bill is double. Here's the comparison framework — workload, VRAM, bandwidth, region, setup friction — that actually predicts your monthly cost. Open the comparison spreadsheet for GPU VPS providers and the first column is always *hourly price*. RunPod $0.34/hr for an A100. Lambda $1.10/hr. Vast.ai $0.23/hr if you take a community node. Hetzner GPU $0.80/hr. This column is the most prominent and the least useful. Two providers with identical hourly rates can produce wildly different monthly bills depending on the workload. A provider that's twice as expensive per hour can be cheaper per *finished job* if its setup is faster, its bandwidth is higher, or its GPU is genuinely twice as fast at your specific load. The right comparison framework is a checklist that translates hourly price into real cost. Here's the framework, with how to apply each dimension. ## Dimension 1: what is your actual workload? Stop comparing GPUs in abstract; start comparing them on what you're going to run. **Inference of small models (≤13B params).** Memory is the binding constraint, not raw compute. An A6000 with 48GB VRAM may beat an A100 with 40GB at half the price. The 40GB A100 forces quantization or split-loading; the 48GB card runs the model whole. **Inference of large models (70B+).** Two A100 40GB outclass one A100 80GB only if your framework supports tensor parallelism cleanly. If not, single big-memory cards win. **Fine-tuning.** Compute and memory both matter. The right balance depends on the fine-tune type (LoRA vs full). LoRA can run on smaller VRAM; full requires high memory. **Training from scratch.** You probably aren't doing this on a VPS. If you are, ignore most of this guide and rent reserved capacity from a hyperscaler. **Image generation (Stable Diffusion, SDXL, FLUX).** Memory matters, but throughput per dollar is the real metric. RTX 4090 community boxes often crush A100 setups on cost-per-image. **Embeddings.** Sequential throughput matters more than VRAM. Older T4 or L4 cards can be the right tool. **RAG / Vector search.** GPU is rarely the bottleneck; bandwidth and CPU are. You might not need a GPU VPS at all. List your actual workload first. Only then look at GPU options. ## Dimension 2: VRAM is the gating constraint for most loads For anything LLM-related, VRAM is the constraint that decides whether your model runs *at all*. Performance comparisons are pointless if the model OOMs. Rules of thumb: - **7B model, fp16:** ~14GB minimum. - **13B model, fp16:** ~26GB minimum. - **34B model, fp16:** ~68GB minimum. - **70B model, fp16:** ~140GB minimum (so multi-GPU). - **Quantization (4-bit) ~halves these.** Add 30-40% for context and KV cache during inference. Add more for fine-tuning state. When comparing providers, lay out the VRAM column next to the price column. Sort by *fits-your-model-yes/no* first; sort by price within the yes group. ## Dimension 3: sustained performance vs benchmark performance Marketing benchmarks are usually short-burst. A GPU that hits 90 TFLOPS for a 30-second test may thermal-throttle to 70 over a long inference job, especially in dense rack setups. Ways to check: - Look for benchmark data from real users on Reddit (r/LocalLLaMA is a good source). - Compare provider reviews mentioning thermal throttling or noisy neighbor issues. - For community marketplaces (Vast.ai), check the host's reliability score and review history. - For new hardware (H100, H200), check whether the provider has actually deployed the GPU you're buying or whether it's a marketing page. Sustained performance is the metric that determines *time-to-finish* on a long job. Time-to-finish is what determines real cost. Hourly price × hours = bill. ## Dimension 4: bandwidth and storage GPU VPS shoppers chronically underestimate the cost of data movement. **Outbound bandwidth.** Providers vary 100x on this. RunPod includes generous outbound on its newer machines; some hyperscalers charge per GB. If your workload returns large outputs (images, video, model weights), this can dominate the bill. **Storage.** Some providers offer ephemeral local SSD only; some offer persistent block storage at extra cost. If you need to keep model weights between runs, persistent storage matters. Otherwise, you're re-downloading the model every session. **Network attached storage performance.** If the provider's persistent storage is slow, model load times can rival actual inference times. "Cheap GPU, slow disk" produces high effective cost-per-task. Lay out the storage and bandwidth columns explicitly. Calculate what your workload moves. ## Dimension 5: region Latency from your users to the GPU matters for interactive use cases (chat-style inference, image generation triggered by user actions). Things to consider: - Where are your users? - Where is your data? - Are you subject to data residency requirements? - Does the provider have a region near both? For batch workloads, region is irrelevant. For real-time, it can be the deciding factor. EU-residency requirements can also limit choices substantially. Some US-only providers have no EU region; some have one. Note this column explicitly. ## Dimension 6: setup friction The time from "reserve a machine" to "run my code" varies wildly: - **Pre-built Docker / templates.** RunPod, Lambda, and a few others ship with PyTorch/CUDA templates. Setup is minutes. - **Bare images.** You install CUDA, drivers, your framework. Setup is hours, sometimes a full day with version mismatch chasing. - **Spot/community machines.** Variable image quality. Sometimes everything works; sometimes you spend longer setting up than running. For short jobs, setup friction can be the largest cost. A $0.20/hr machine that takes 90 minutes to set up costs more in your time than a $1.00/hr machine you can run a 30-minute job on immediately. When comparing providers, estimate the setup time honestly. Include it in the cost. ## Dimension 7: hidden cost amplifiers A few items the spreadsheet usually misses: **Egress for model weights.** If you're using a custom model and you tear down the machine after every session, you pay to re-upload it each time. Persistent storage often pays for itself. **Idle minutes during exploration.** Interactive jobs (notebook sessions) accumulate idle minutes. The cheap hourly machine that's billed by the minute helps; the one billed by the hour doesn't. **Failed runs.** Spot instances that get evicted mid-job count toward your bill but produce no output. Reliability matters. **Support latency.** When the machine has a problem, how long until it's fixed? A 4-hour outage on a $1/hr machine is much worse than the price difference vs a $1.50/hr provider with same-hour support. These five items can easily double the effective cost of the "cheap" provider. ## A practical comparison sheet When evaluating providers, the columns to include: | Column | Why it matters | |---|---| | GPU model + VRAM | Does my workload even fit? | | Sustained perf (tokens/sec for LLM, img/min for diffusion) | Real time-to-finish | | Hourly price | One input among many | | Minimum billing increment | Per-minute vs per-hour matters for short tasks | | Outbound bandwidth + cost per GB over | Output-heavy workloads | | Storage (ephemeral vs persistent) + cost | Re-download model? Keep it? | | Region availability | Latency and residency | | Setup time (template vs bare) | Time-to-first-run | | Reliability / eviction history | Failed runs cost real money | | Support response time | When things break | This sheet predicts the monthly bill way better than the hourly price column alone. ## When the cheap provider really is the right answer For *batch, fault-tolerant, output-light* workloads — embedding millions of documents, batch image generation that doesn't care about reorder, periodic fine-tunes — the cheap community providers (Vast.ai, RunPod Community Cloud, etc.) often genuinely win. The characteristics that make this work: - The job can survive eviction (it's idempotent or checkpoints regularly). - The job doesn't produce huge outbound data. - The job can wait for available capacity instead of needing immediate spin-up. - The job uses a model the provider's image already supports. When those four are true, paying 3-4x for a managed provider is overpaying. ## When the expensive provider is the right answer For *interactive, latency-sensitive, output-heavy* workloads — production chat APIs, real-time image gen tied to user actions, fine-tunes that need full reproducibility — the managed and well-supported providers usually win. The hourly delta is overwhelmed by: - Faster setup → less developer time. - Reliable instances → predictable scheduling. - Better networking → lower egress costs and lower user-facing latency. - Real support → faster recovery from issues. If you can't tolerate the failure modes of cheap providers, the math says pay more. ## The summary GPU VPS comparison is not a sort-by-hourly-price problem. It's a six-axis decision: workload fit (VRAM), sustained perf, bandwidth and storage, region, setup friction, and reliability. Lay out the columns. Calculate the effective cost of *finishing your specific job*. The cheapest hourly often isn't cheapest monthly; sometimes it is. The framework lets you tell which case you're in. --- ## Best single-dashboard app health for self-hosters who aren't ready for Prometheus Source: https://deployhandbook.com/blog/best/single-dashboard-app-health-self-host Published: 2026-06-03 Tags: homelab, dashboard, health-monitoring, self-hosted Homelab and VPS users want one calm dashboard for app health — not a full observability stack. Here are the tools that hit the middle layer between SSH and Grafana. There's a gap in the self-hosting tool landscape that catches a lot of people in the middle. On one side: shared hosting and managed services, where someone else worries about whether your stuff is up. On the other side: a full Prometheus + Grafana + Alertmanager stack, where *you* worry about everything, including the monitoring stack itself. In between is the operator with three to ten apps on one or two VPSes. They want to glance at one page and know whether their things are okay. They do not want to spend a weekend wiring up exporters and dashboards. They want the calm middle. This is a tool comparison for that middle. The shortlist is small because most tools are either too thin or too heavy. The ones that fit the gap do one job well: tell you whether your apps are healthy, in one place, without becoming a project of their own. ## What "calm middle" actually looks like Before the tools, the criteria. A calm-middle dashboard should: - Show every app on one page, with a clear up/down state. - Use simple checks (HTTP, ping, TCP) rather than complex metrics pipelines. - Alert via channels the operator already uses (email, ntfy, Slack, Discord, Telegram). - Run as one container or one binary, not a stack. - Be debuggable in a single afternoon if something breaks. - Survive its own restart without losing history. If a tool ticks those six, it qualifies. Most don't. ## The shortlist Five tools cover the calm-middle category well. Different shapes, similar payoff. ### Uptime Kuma The default recommendation in this category. Self-hosted, single container, web UI for monitors and notifications. Supports HTTP, ping, TCP, DNS, push (heartbeat-style), and a couple of dozen integrations for alert channels. **Strengths:** - Setup is one Docker container. - The status page builder is built in — share a public page if you want. - Alert channels cover essentially every notification surface. - Maintenance windows let you suppress alerts during planned work. - Active development; community is large. **Weaknesses:** - The UI shows individual monitors well but doesn't group them logically for very large fleets. - Long-term metric history is shallow; you get the latest state and a small window of past status. - Some alert channels need version-specific config tweaks. **When it's the right pick:** you have under 50 monitors, want a public status page, and want one tool to do it all. ### Beszel Newer entrant, also self-hosted. Designed around an agent-on-each-host model: each VPS runs a small Beszel agent, the hub UI shows a consolidated view. Adds light resource metrics (CPU, mem, disk, network) per host on top of the uptime checks. **Strengths:** - Per-host resource view is genuinely useful — answers "is my VPS healthy?" not just "is my app reachable?" - Docker-aware: shows running containers per host. - Lightweight; agents are small. - Modern UI. **Weaknesses:** - Newer; community and integration surface are smaller than Kuma's. - Agent installation on every host is a step Kuma doesn't require. - Alerting integrations are fewer. **When it's the right pick:** you have several VPSes and want the agent-style resource visibility alongside uptime checks. ### Glances + a small dashboard Glances is a Python tool that shows everything about a host in a TUI. With its API, you can wire multiple Glances instances into a small dashboard. **Strengths:** - Zero-friction install (pip or Docker). - Very detailed per-host info. - Composable; you can build the exact dashboard you want. **Weaknesses:** - The "one page for all my apps" experience is something you build yourself. - Alerting is bring-your-own. - Not really a turnkey product. **When it's the right pick:** you want per-host detail and you're willing to assemble the dashboard. ### Cockpit (with the right modules) Red Hat's Cockpit gives you a web UI per host with system state, services, containers, storage, and updates. It's not a fleet dashboard out of the box, but with multi-host configured, it works for small clusters. **Strengths:** - First-class system management (services, updates, storage). - Light to install on each host. - Integrates with systemd cleanly. **Weaknesses:** - App-level health is not its strength; this is more of a host-management UI. - Cross-host overview is limited. - Alerting needs to be wired separately. **When it's the right pick:** you want system management more than app uptime, and you're already on Fedora/RHEL/Debian where Cockpit fits naturally. ### Checkmk Raw (free edition) The heaviest option on this shortlist. Full monitoring suite with agents, host views, services, metrics, and alerting. Free Raw edition is genuinely capable for small fleets. **Strengths:** - Real metric history, not just status. - Powerful alerting and notification rules. - Scales up if your needs grow. **Weaknesses:** - Significantly more to learn than the others. - Installation is heavier — a real appliance, not a single container. - The full UI surface can feel overwhelming for small setups. **When it's the right pick:** you suspect you're going to outgrow Kuma within six months and want a tool that grows with you. ## Decision shortcut If you're starting today and just want to make a choice: - **Under 10 monitors, want a status page:** Uptime Kuma. Stop reading. - **Several VPSes, want resource and uptime in one:** Beszel. - **Mostly system admin (services, updates):** Cockpit. - **Will need metric history within six months:** Checkmk Raw. - **Want to compose your own:** Glances + a script. Most setups land at Uptime Kuma. It's the default for a reason. ## What none of these are None of the tools in the calm middle are full observability suites. They don't give you distributed tracing. They don't give you long-term metric history with high cardinality. They don't give you log aggregation. They aren't trying to. The trade is that you get the answer to "is anything broken?" in one page, with very little setup overhead. If you need more — actually need it, not theoretically — then the right move is Prometheus + Grafana + Loki + Alertmanager, with the expectation of running that stack as its own ongoing project. For most homelab and small-VPS operators, the trade is correct. The calm middle is enough. ## What the wrong tool feels like A few signs you've picked the wrong layer. **Too thin.** You learn about outages from your users. Your uptime tool noticed but didn't alert you usefully. Either upgrade the alert channels or upgrade the tool. **Too thick.** You spend an hour a week maintaining the monitoring stack itself. Reduce scope or swap to a lighter tool. **False positives.** Alerts fire constantly without real outages. Either the checks are too aggressive (lower the frequency, raise the threshold) or the dependencies are flaky (add maintenance windows or change what you're checking). **Underused.** The dashboard exists but nobody looks at it. The signal isn't reaching anyone. Wire the alerts into a channel the operator actually reads. When any of these happen, the fix is usually to swap layers — not to add more configuration to the wrong tool. ## Common alert channels worth wiring Whatever tool you pick, the *alerting destination* matters more than the dashboard. **ntfy.** Push notifications without an account. Free, fast, runs on a self-host server if you want. **Telegram or Discord.** Free, fast, you're probably already in those apps. **Email.** Reliable, but slow. Good for non-urgent. **Slack.** Fine if your team is on Slack. Otherwise overkill. **Phone call (PagerDuty, Opsgenie).** Only if you have on-call rotations. A mix is usually right: ntfy for everything, email as backup, escalation to phone only for critical. ## A short setup checklist For any of the tools in the shortlist: - [ ] Run the container (one Compose file). - [ ] Add a monitor for each app — start with HTTP checks on the public URL. - [ ] Add an alert channel (ntfy or email or Discord). - [ ] Send a test alert. - [ ] Add a maintenance-window for planned deploys. - [ ] If you have multiple hosts, install the agent on each. - [ ] If you want a public status page, configure it. - [ ] Verify the dashboard URL is reachable from your phone (you'll want it there). With this list checked, the dashboard is doing the job. Look at it once a day, react when it alerts, and ignore it the rest of the time. That's the calm middle. ## The summary The gap between shared hosting and a full Prometheus stack is real. The calm middle is filled by a small number of single-dashboard tools — Uptime Kuma being the default, with Beszel, Cockpit, Glances, and Checkmk Raw covering specific cases. Pick the one that matches your fleet shape; wire alerts into a channel you actually read; don't try to make it do more than tell you whether your apps are okay. --- ## Proxmox panels vs lightweight deploy tools — which one do you actually need? Source: https://deployhandbook.com/blog/compare/proxmox-panels-vs-lightweight-deploy-tools Published: 2026-06-03 Tags: proxmox, deploy-tools, server-panels, homelab, vps-management Homelab and VPS users keep conflating infrastructure management with application deployment. Here's how to tell whether you need a full Proxmox-style panel or just a deploy layer with monitoring. Walk into r/homelab or r/selfhosted and ask "should I use Proxmox or Coolify?" The thread fills up fast, opinions are loud, and the answers usually miss the actual question. Proxmox and Coolify aren't competitors. They live at different layers. Asking which one you need is like asking whether you need a hypervisor or a deploy tool — the right answer depends on what problem is actually slowing you down. This guide separates the two layers, then helps you tell which one is your bottleneck. ## The two layers, in plain terms **Infrastructure layer (Proxmox).** Manages the physical or virtual servers themselves. Creates VMs, allocates CPU and RAM, attaches disks, networks them together. Answers "how many machines do I have and what are they running?" **Deployment layer (Coolify, Dokploy, CapRover, etc.).** Manages the applications running on the machines. Builds them, deploys them, sets up reverse proxies and TLS, exposes a UI for monitoring. Answers "what's running and how do I update it?" A full setup has both layers. Proxmox at the bottom handles the VMs; a deploy tool inside one of those VMs handles the apps. Or you skip Proxmox entirely and run a deploy tool directly on a single VPS — that works too, for smaller setups. The question isn't "which one," it's "which one am I missing?" ## When you need a Proxmox-style panel Proxmox earns its place when you have one of these problems: **Multiple physical or virtual machines you need to manage as one fleet.** Two or more bare-metal boxes in a homelab. A small business with three or four servers. The question "which box is this VM on" has stopped being trivial. **You want VM-level isolation for different workloads.** A production app on one VM, a development environment on another, a media server on a third — all on the same hardware. Containers don't isolate at the same level; VMs do. **You're playing with operating systems other than Linux.** Running Windows VMs, BSD, or specialty appliances. Proxmox lets you mix. **You need snapshots, live migration, or replication.** Storage features that exist at the VM level. Backing up an entire VM to another node, moving a running VM between hosts without downtime, replicating to a second cluster. **You're virtualizing GPUs or doing PCIe passthrough.** Workloads that require direct hardware access through the hypervisor. These are all real needs. If two or three of them are pressing for you, Proxmox is the right substrate. If none of them are, Proxmox is overhead. You're running a hypervisor when a single OS install would have been enough. ## When you need a lightweight deploy tool Coolify, Dokploy, CapRover, Dokku, and similar tools earn their place when: **You have a handful of apps and want them to deploy themselves.** Git push, the tool builds, the tool deploys, TLS gets handled. The day-to-day operation is invisible. **You're tired of writing the same Docker Compose + Caddy + Let's Encrypt boilerplate every time.** A deploy tool gives you the shortcut. **You want a UI for non-engineer collaborators.** A teammate who doesn't `ssh` needs to be able to see app status. Deploy tools provide that surface. **You want a one-click rollback.** Most deploy tools provide release history and revert. **You want managed databases as a primitive.** Spin up Postgres for this app, MySQL for that one, Redis for a third — without writing the YAML each time. These are the day-to-day chores of running self-hosted apps. The tool gives you the shortcut. If you're running zero or one app and you don't need the UI, a deploy tool is overhead too. A single `docker compose up -d` is fine. ## How most homelabs misroute the question A few common confusions: **"I want a UI to see my apps, so I need Proxmox."** No — you need a deploy tool. Proxmox's UI is for VMs, not apps. The app dashboard is what Coolify or Dokploy gives you. **"I have one VPS, should I run Proxmox on it?"** Almost certainly not. Proxmox shines when it has multiple machines to coordinate. On a single VPS, it adds layers and complications without the corresponding benefit. **"I want to run multiple unrelated apps; I need Proxmox."** Usually no — you need Docker. Container isolation is enough for most app-level separation. Proxmox is only needed when you also want OS-level isolation. **"Coolify lets me create VMs."** It doesn't (and shouldn't). Coolify manages apps. If you need VMs, you need a hypervisor underneath. These confusions are honest because the marketing for both layers overlaps in their dashboards. Both tools show you "things you have." The thing they're showing is different. ## A decision tree A practical way to decide: 1. **Do you have more than one machine?** - Yes → consider Proxmox (or its cluster cousins, or Kubernetes if your workloads justify it). - No → don't need a hypervisor panel. 2. **Do you need to run heterogeneous OSes (Windows, BSD) or do PCIe passthrough?** - Yes → Proxmox or similar. - No → Linux + Docker is probably fine. 3. **Do you have more than one app to deploy and update regularly?** - Yes → a deploy tool (Coolify, Dokploy, CapRover, Dokku, etc.) is high-value. - No → a Docker Compose file by hand is fine. 4. **Do you want a UI for non-engineer collaborators?** - Yes → a deploy tool. - No → SSH and CLI are enough. 5. **Do you want managed databases without writing YAML?** - Yes → a deploy tool that exposes DB as a primitive (Coolify, Dokploy). - No → roll your own. Different answers route to different stacks: - **Single VPS, several apps, want UX:** Coolify or Dokploy on the VPS. No Proxmox. - **Multiple bare-metal boxes, several apps:** Proxmox underneath, Coolify or Dokploy inside one or more VMs. - **Multiple boxes, no UX needs:** Proxmox + plain Docker Compose. - **One box, one app:** Docker Compose alone. Skip both layers. - **Homelab with mixed OSes:** Proxmox at the base. Deploy tool for Linux app subset only. ## The hybrid case is common Many real homelab setups end up with both. A Proxmox cluster hosts VMs. One VM runs Coolify and the apps. Another VM runs a NAS or a media server. A third runs a development sandbox. In this shape, Proxmox is about *machines*. Coolify is about *apps*. They don't overlap. This hybrid setup scales better than either alone. The hypervisor lets you isolate workloads and snapshot at the VM level. The deploy tool keeps the app layer cheap and ergonomic. If a Coolify VM corrupts, you restore from a Proxmox snapshot and you're back. If an app fails, you roll back inside Coolify and the rest of the VMs are untouched. ## Lightweight alternatives to Proxmox If Proxmox feels heavy and your needs are modest, the alternatives: - **XCP-ng.** Open-source XenServer fork. Similar feature set to Proxmox; different mental model. - **Incus (formerly LXD).** Container-and-VM management without the panel weight. Closer to a CLI. - **Libvirt + Cockpit.** Plain libvirt managed via Cockpit's UI. Simpler, less feature-rich. - **None.** If you have one box and need container isolation but not VM isolation, just run Docker on the host. Most "I want something like Proxmox but lighter" requests end up at *no hypervisor at all*. The desire for the UI was masking the fact that the VMs weren't earning their place. ## Lightweight alternatives to Coolify If Coolify feels heavy and your needs are modest: - **Dokploy.** Similar shape, often a little simpler. - **CapRover.** Older, simpler model. - **Dokku.** CLI-driven Heroku-style. - **Plain Docker Compose + Caddy + Watchtower.** No UI, but covers most of what a deploy tool gives you. - **A shell script.** For very small setups with one or two apps that change rarely. The lighter you go, the more discipline you need on conventions. The heavier tools enforce more for you. ## What the Reddit thread is actually asking When someone in r/homelab asks "Proxmox or Coolify," they usually mean one of: - "I want a dashboard for my apps and I don't know the right tool." → Coolify or Dokploy. - "I have multiple machines and don't know how to orchestrate them." → Proxmox. - "I want both, but I'm confused about which is which." → Both, layered. - "I'm overwhelmed by my current setup." → Probably none yet; simplify first, add a layer when you know which one is missing. If you can name which of those four maps to your case, the rest of the decision falls out. ## A short version Proxmox and lightweight deploy tools live at different layers. Proxmox manages machines; Coolify and friends manage apps. Most "which should I use" questions are really "which layer am I missing?" Decide by listing the problems you have now (multiple machines, multiple apps, want a UI, need OS isolation) and let those route you. The wrong move is to pick one and assume it covers the other layer; the right move is to install only what your current pain demands and add the other layer when it earns its place. --- ## Low-noise uptime checks: alert thresholds that survive a homelab full of services Source: https://deployhandbook.com/blog/best/low-noise-uptime-checks-homelab Published: 2026-05-14 Tags: selfhosted, monitoring, alert-fatigue, uptime, homelab, alerting, uptime-kuma, gatus Run twenty self-hosted services on a homelab and the default uptime-check thresholds will page you ten times a week for nothing. Most of the noise is design, not bad luck — single-probe checks, no flap suppression, severity treated as binary. Here's the configuration that quiets the alerts without losing real outages. A homelab with twenty services is normal now. Pi-hole, Home Assistant, Jellyfin, Nextcloud, Vaultwarden, Immich, Paperless, Gitea, a couple of game servers, three monitoring tools watching the other seventeen — twenty isn't even ambitious. The problem is that every uptime tool, by default, treats those twenty services as twenty independent things to ping every 60 seconds with a single check, alerting on the first miss. Run that for a week and you'll get paged for a Pi-hole DNS blip at 3am, a Jellyfin transcoder hiccup during a movie, and a Gitea connection refused that resolved itself in eight seconds. Three weeks in, you're ignoring the channel — which is when the real Nextcloud outage will pass through silently. The noise isn't a tool problem. Uptime Kuma, Gatus, Healthchecks, Statping, Cabot — all of them can be configured to quiet down. They ship loud because shipping quiet would mean opinionated defaults nobody agrees on. The shape of "low-noise but trustworthy" is consistent across communities though, and once you've configured it once you stop debating it. Four levers do almost all the work. ## Lever 1 — agreement, not single-probe The single biggest source of false alerts in homelab monitoring is a single check failing once and the alerter firing immediately. Network blips, brief CPU spikes, container restarts, NTP-driven brief unreachability — every one of these produces a transient failure that nobody needs to know about. Replace single-probe with *agreement*. A service is only "down" if two consecutive checks fail, or if two checks from different vantage points fail in the same window. Both rules cut roughly 80% of transient noise without weakening real-outage detection. Concretely: - **Two-consecutive-fail rule** — the check has to fail twice in a row, with the standard interval between, before the state flips. For a 60-second check that means a service has to be down for ~120 seconds before you get a page. For Jellyfin, you genuinely don't care about 90-second outages. - **Multi-vantage agreement** — if you have a second probe (a second Pi running Uptime Kuma, a small VPS, or even a tunnel back from a phone), require both to see the failure. Half of single-vantage outages are *the monitor's network*, not the service. Most tools ship a setting for the first; the second requires running two probe instances. Both pay back the setup cost in the first week. ## Lever 2 — flap suppression The second source of noise is the service that goes up, down, up, down across two minutes — usually a container that's restarting, a port that's being rebound, or a TLS handshake that's racing a certificate refresh. Each transition is a separate alert. Five flaps in two minutes is five pages. Flap suppression collapses the storm. The two patterns worth implementing: - **State debounce** — when a service's status changes, lock the new state for N minutes before allowing another transition alert. N = 5 minutes is the homelab default; N = 15 minutes for noisy services like media transcoders. - **Alert suppression window** — if more than M alerts fire for the same service in a rolling window, suppress further alerts and roll them up into a single "flapping" notification at the end of the window. M = 3 in a 10-minute window catches most flap storms. Both keep the *information* (the service is misbehaving) while killing the *page-count*. Gatus and Uptime Kuma both support state debounce natively; alert suppression usually lives in your notifier (Apprise, ntfy, or a downstream rule in your channel of choice). ![Three severity tiers: household-critical, personally-important, optional](https://assets.stoicsoft.com/posts/deployhandbook/low-noise-uptime-checks-homelab/three-tiers.png) ## Lever 3 — tiered severity, not boolean The instinct to treat "up" and "down" as the only two states is what makes operators page themselves for things that don't need a page. A homelab inventory naturally sorts into three tiers, and each tier wants a different alerting destination. - **Tier 1 — household critical.** Pi-hole, the router, the firewall, the wireguard endpoint. If these are down for >2 minutes, you want a phone notification. Anyone in the house notices the outage within minutes anyway, so the alert is just the on-call confirmation. - **Tier 2 — personally important.** Nextcloud, Vaultwarden, Immich, Paperless, Gitea, your blog. Down for >5 minutes should produce a notification to your monitoring channel — Slack, Discord, ntfy, whatever you actually read. Not a phone call. - **Tier 3 — fun but optional.** Jellyfin, game servers, dashboards, lab utilities. Down for any length of time → no immediate alert. A daily digest at 9am that says "these things have been down for >12 hours" is plenty. Most tools let you set per-monitor notification rules. The trap is treating this as a per-monitor decision instead of a tier decision — twenty per-monitor configs drift; three tier-templates don't. ## Lever 4 — silence-by-default for new services The last source of noise comes from new services. You spin up a new homelab toy, hook it into Uptime Kuma to "watch it," and now every container restart for the next week pages you while you're still tuning the service itself. Make silence the default for new monitors. Concretely: every new monitor starts in Tier 3 (daily digest only) for the first 14 days. After 14 days, you've seen how it behaves and you promote it to the tier it actually deserves. Most Tier 3 services stay Tier 3 forever, which is fine. A monitor that lives in Tier 1 should have justified its way there. Default-quiet plus deliberate promotion is the only policy that scales to twenty-plus services without burning the operator out. ## Putting it together: a working ruleset A homelab ruleset that survives twenty services looks roughly like this: ```yaml # All monitors checks: interval: 60s fail_threshold: 2 # Lever 1 — two-consecutive recovery_threshold: 2 # don't flip back too eagerly state_debounce: 5m # Lever 2 — flap suppression alert_burst_window: 10m alert_burst_max: 3 severity_tiers: household_critical: # Lever 3 — Tier 1 services: [pihole, router, wireguard] notify_after: 2m channels: [phone, ntfy_priority_max] personally_important: # Tier 2 services: [nextcloud, vaultwarden, immich, paperless, gitea, blog] notify_after: 5m channels: [slack_homelab] optional: # Tier 3 services: [jellyfin, gameserver, dashboards, lab_*] notify_after: 12h channels: [daily_digest] new_monitor_default_tier: optional # Lever 4 — silence-by-default new_monitor_quarantine_days: 14 ``` This isn't a real format any single tool consumes. It's the shape of the policy you encode into whichever uptime tool you run. Translate each section into the relevant settings (state debounce, notification routing, default tags), and your alerts go from ten a week to three a week — with the three being real. ## What to wire it into Four tools cover the homelab uptime space well, with different tradeoffs (and one hosted option — [ServerCompass](https://servercompass.app) — wires the four levers above into sensible defaults if you'd rather not maintain your own monitor): - **Uptime Kuma** — the popular default. Good UI, good notifier coverage, supports interval + fail-threshold natively. Less elegant for multi-probe agreement (you run two instances and reconcile manually). - **Gatus** — declarative YAML config, good for ops people who prefer git-managed configs to UIs. Supports conditional alerting ("alert if X failed AND Y didn't") which is useful for the multi-vantage rule. - **Healthchecks.io (self-hosted)** — different model: services *check in* with the monitor on a schedule. Excellent for cron jobs and batch services; less natural for HTTP uptime. - **Apprise / ntfy** — not monitors themselves; they're the notification layer. Both support the alert-burst suppression and priority routing you need to make tiered severity actually work. A practical homelab stack picks one monitor (Uptime Kuma or Gatus) plus one notifier (ntfy + Apprise on top is the modal answer in 2026), wires them to the rule shape above, and stops re-tuning every two weeks. ## Why this is worth doing once Alert fatigue isn't a vibe. It's the predictable outcome of running a default-loud alerting system across a heterogeneous service inventory for more than a few weeks. The cost is real: you stop reading the channel, you miss the one alert that matters, and your homelab feels less reliable than it actually is. The configuration above takes about an hour to set up the first time and ten minutes to re-apply when you add a new service. After three weeks, your alert count drops by roughly an order of magnitude, and the alerts that remain are the ones you want. It's not a tool problem. It's a policy problem with a known shape — agreement, flap suppression, tiered severity, silence-by-default — and the homelab community has converged on this exact shape from the bottom up. Pick a monitor that supports the four levers, encode the policy, and stop debating it. The point of running services at home is using them, not babysitting an alerting channel. --- ## How to Evaluate a VPS Provider for Migration Safety (Not Just Price) Source: https://deployhandbook.com/blog/best/migration-safe-vps-evaluation Published: 2026-05-05 Tags: vps-provider, migration, reliability, ops-risk Most VPS migration disasters trace to the workflow, not the destination. The seven verifications and four-phase migration playbook. Most VPS migration horror stories share a structure: someone sees a cheaper provider, signs up, copies files over, DNS-flips, and discovers the new host has a quieter IP that the user's email gets routed through suddenly fails sender-reputation checks — or that the old provider's "snapshot backup" was actually only of the boot disk, not the data volume. Or that the migration plan was right but the rollback wasn't tested. Migration safety isn't about the destination provider. It's about the *workflow*. A safe migration plan is identical regardless of who you're going to. This is the playbook. ## Before you migrate: the seven verifications ### 1. Provider reputation, but on the right axes Cost and benchmarks aren't enough. Check: - **PTR/reverse DNS policy** — can you set custom rDNS on your IPv4 (and IPv6) without paying extra? Critical for email and any service whose receivers check rDNS. - **IP reputation** — search the destination provider's IP range on Spamhaus, Barracuda, AbuseIPDB. Cheap providers often have ranges that are pre-flagged. - **Network reliability** — find recent "incidents" pages or status histories. A provider with monthly partial outages is a hidden tax. - **Egress costs** — surprisingly variable. Some providers charge per-GB for outbound, some include it. - **DDoS handling** — is mitigation included or is it a crisis bill when it happens? A provider that's $3/month cheaper but has a flagged IP range will cost you 4 hours of email-deliverability debugging. Net: negative ROI. ### 2. Data inventory Before you migrate, write down: - Application code paths (`/var/www`, `/srv`, etc.) - Database paths and dumps - Config files (`/etc/nginx`, `/etc/letsencrypt`, app-specific configs) - Cron jobs (`crontab -l` per user, `/etc/cron.d/`, `/etc/crontab`) - Mounted volumes / disks - Any state in `/var/lib/` (Postgres data, Redis dumps, etc.) - Service files in `/etc/systemd/system/` - SSL/TLS certificates and renewal hooks - DNS records (TTLs, MX records, TXT records) Sounds tedious. Skip one item and the migration produces a "it worked, except…" outcome. ### 3. Snapshot, dump, and verify For every database: ```bash # Postgres pg_dumpall -U postgres > /backup/all-$(date +%Y%m%d).sql # MySQL mysqldump --all-databases --single-transaction --triggers --routines --events > /backup/all-$(date +%Y%m%d).sql # Verify the dump can restore on a different machine before continuing. ``` The third step (verify on a *different* machine) is what separates "I have a backup" from "I have a backup that works." Many migration disasters are dumps that turned out to be empty or corrupted. ### 4. Test the rollback path Before you start, ask: if this migration fails halfway, how do I get back to the original? - DNS TTL: lower it to 300s a day before the migration. After migration, you can flip back fast if needed. (Otherwise you're stuck waiting hours.) - Old server: do not destroy for at least 7 days after the cutover. - Test the rollback DNS flip on a non-production service first. ### 5. Time the cutover Pick a low-traffic window. For most B2B SaaS this is 02:00 in the user's primary timezone, on a Saturday. Avoid: - Mondays (people notice) - The first or last day of the month (billing runs) - The week of a major release - Holiday weekends (no support staff) ### 6. Build the runbook Write the cutover steps in advance. Each step should have: - The exact command(s) to run - The expected output (so you can verify) - A "what if this fails" branch This is the difference between a 20-minute cutover and a 3-hour panic. The runbook is also what your post-migration review uses. ### 7. Test the new server's basics Before the cutover, on the new server: - `curl -I localhost:443` — does the app respond? - `mail -s test you@example.com` — does outbound mail work? - `dig +short example.com @1.1.1.1` — does DNS resolve correctly? - `df -h` — is there room? - `free -m` — is there RAM headroom? Don't migrate to a server you haven't smoke-tested. ## The migration day ### Phase 1 — sync data while old server is live ```bash # rsync app files repeatedly to converge rsync -avz --delete /var/www/ newserver:/var/www/ # Final database dump and copy pg_dumpall -U postgres > /tmp/final.sql scp /tmp/final.sql newserver:/tmp/ ``` Run rsync several times in the days before. Each subsequent run is faster. The final run on cutover day is then a small delta. ### Phase 2 — quiesce old, restore on new 1. Stop writes on the old server (read-only mode if your app supports it; otherwise downtime starts here). 2. Final rsync. 3. Final database dump. 4. Restore database on the new server. 5. Start the app on the new server. 6. Smoke-test on the new server (using the new IP, not DNS). ### Phase 3 — flip DNS Once smoke tests pass on the new server's IP, flip the A record. With TTL at 300s, propagation is mostly done in 10-30 minutes. If you have a load balancer in front, this is even smoother — flip backends, observe traffic shift, decommission old when stable. ### Phase 4 — verify and watch - Watch error rates for an hour. - Verify SSL handshakes succeed. - Verify email deliverability with a test send to Gmail, Outlook, ProtonMail. Check spam folders. - Verify cron jobs ran on the new server (or are scheduled to). - Verify monitoring alerts work from the new IP. ## Internal links - Guide: [VPS Backup Strategy](/guide/backup-strategy) - Guide: [SSL Certificates with Let's Encrypt](/guide/ssl-certificates) - Tutorial: [Self-Host Uptime Kuma on a VPS](/self-host/uptime-kuma) - ServerCompass: [Compare VPS providers](https://servercompass.app/?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) ## When migration is the wrong answer A reminder: most "I should switch VPS providers" instincts are wrong. Costs are usually 5-10% different. Switching costs are 10-40 hours of engineering time plus risk. Unless your current provider is genuinely failing you (frequent outages, no rDNS control, blocked ports), staying put and tuning is almost always the better trade. The migrations that actually pay back: - Moving from a managed PaaS (Heroku/Render/Railway) to a VPS to escape per-dyno pricing. - Moving from a small VPS to a bigger one when you've outgrown the resource ceiling. - Moving from a provider with persistent reliability problems to one with a track record. If your reason is "this provider seems cheaper" — measure twice. The cheap migration is usually the expensive one. --- **Related in the StoicSoft network** If you're self-hosting on a VPS or working through a deployment guide like the one above, [DeployToVPS](https://deploytovps.com) is the StoicSoft network's handbook for VPS deployment recipes — docker-compose, nginx, traefik, and common app self-hosts. --- ## Coolify vs Kubernetes: Which Is Production-Ready for Your Team? Source: https://deployhandbook.com/blog/compare/coolify-vs-kubernetes Published: 2026-05-05 Tags: coolify, kubernetes, production-readiness, platform-choice Coolify and Kubernetes live at opposite ends of an operational complexity scale. The honest sizing decision (it isn't binary). "Should I use Coolify or Kubernetes in production?" is one of the most common deployment questions on subreddits like r/selfhosted and r/devops. The wording suggests a binary choice — but the framing is wrong. These two tools live at opposite ends of an operational complexity scale. Picking between them isn't a technical decision; it's a sizing decision. The question is what kind of operational load your team can absorb without losing the plot of why you're shipping software in the first place. Here's the honest comparison. ## What each tool actually is **Coolify** is a self-hosted PaaS, similar in shape to Heroku or Render. It runs on a single VPS (or a small cluster), provisions Docker containers, handles SSL via Traefik, and deploys from a Git push. **Kubernetes** is an orchestration platform that runs containers across many nodes, with rich primitives for scheduling, networking, secrets, and stateful workloads. Saying "Coolify or Kubernetes" is like saying "a Honda Civic or a freight train." Both move things. The choice depends on what you're moving and how often. ## When Coolify is the right answer You should pick Coolify (or a similar single-host PaaS like Dokploy, CapRover, or Plesk) when: - **Your traffic fits on one server.** Most B2B SaaS apps with up to 50,000 monthly users fit easily on a $30-$100/month VPS. - **You don't have a dedicated platform/infra engineer.** Coolify can be operated as a side activity by an application engineer. Kubernetes cannot. - **Your services are mostly stateless web apps + a few databases.** This is the sweet spot. - **Cost matters more than cloud-native ergonomics.** A single $50/month VPS running Coolify replaces a $400/month managed Kubernetes cluster for many workloads. - **You don't need geographic redundancy.** If your users are in one region, you don't need a multi-region setup. - **You're early-stage and need to iterate on the product, not the infrastructure.** A typical Coolify deployment looks like one VPS with 2-8 vCPUs, 8-32 GB RAM, hosting 5-20 services (web app, API, cron, Redis, Postgres, observability stack), and serves real production traffic for months without pager events. ## When Kubernetes earns its complexity You should pick Kubernetes when: - **You actually need horizontal scaling across nodes.** Single-host limits become real (one machine's RAM/CPU/disk). - **You have stateful workloads with HA requirements** that aren't trivially solvable on one machine (e.g. Postgres with synchronous replicas across regions). - **You have a dedicated platform team.** Operating Kubernetes well requires people who think about it as a product, not a tool. - **You need rich multi-tenancy** — namespaces, RBAC, resource quotas across many teams. - **Your traffic is large enough that the per-pod efficiency matters.** Below a certain scale, the orchestration overhead is bigger than the wins. - **Your compliance or contracts require multi-AZ / multi-region**, and Kubernetes is the standard your auditors recognise. A "real" Kubernetes deployment is rarely just a control plane and a few worker nodes. It includes ingress (NGINX/Traefik on K8s), cert-manager, observability (Prometheus + Grafana), secrets management (External Secrets Operator), GitOps (ArgoCD or Flux), and at least one full-time engineer who knows how it all fits together. ## The honest comparison table | Concern | Coolify | Kubernetes | |---|---|---| | Setup time | 30 min | 2-30 days for production-grade | | Recovery from total host failure | Manual (restore from backup) | Automated (pod reschedules) | | Multi-region | Not native | Supported, but complex | | Secrets management | Env vars in UI | First-class (with External Secrets) | | Cost at small scale | $30-$100/mo VPS | $200-$1000+/mo cluster | | On-call burden | Low (occasional) | Medium-high | | Required skill set | Docker, Linux ops | Above + K8s primitives | | Vendor lock-in | None ([Docker compose](https://servercompass.app/features/docker-compose-editor) underneath) | Some (CRDs, operator patterns) | ## The middle path most people miss For teams that have outgrown a single VPS but aren't ready for Kubernetes, the middle path is *managed* Kubernetes (EKS, GKE, AKS, DigitalOcean Kubernetes) with conservative configuration: - Two or three nodes. - A small set of well-known charts (Helm). - A managed database service (RDS / Cloud SQL / Hetzner managed Postgres) instead of running Postgres in-cluster. - A boring ingress (NGINX or Traefik) instead of a complex service mesh. This avoids the "production Kubernetes is a full-time job" trap by deliberately not using 80% of Kubernetes' features. You get pod scheduling, rolling deploys, and horizontal scaling — and skip Istio, Linkerd, custom CRDs, and bespoke operators. For teams running Coolify and feeling growing pains, this is usually a better next step than going from Coolify directly to a full DIY Kubernetes setup. ## The decision framework Three questions, in order: 1. **Does your traffic fit on one server, with headroom for spikes?** - Yes → Coolify. 2. **Does your team have a dedicated platform engineer?** - No → managed Kubernetes (EKS / GKE) with minimal customisation, or stay on Coolify and grow vertically. 3. **Do you actually need multi-region, multi-cluster, or rich multi-tenancy?** - Yes → full Kubernetes is justified. Most teams answer "yes" to question 1 longer than they think. The traffic numbers that *force* you off a single host are larger than most ICs and founders assume — typically only at hundreds of thousands of monthly active users with non-trivial per-user load. ## What "production-ready" actually means Both tools can run production workloads. Production-readiness isn't about Coolify vs. K8s — it's about: - **Backups that you've tested restoring.** - **Monitoring that pages someone before users notice.** - **A runbook for the top 3 incident classes.** - **A staging environment that meaningfully resembles production.** - **Secret management that isn't just env vars in chat.** - **Deploy rollback that takes < 5 minutes.** A team running Coolify with all six checked is more production-ready than a team running Kubernetes with none. ## Internal links - Compare: [Render vs Railway](/compare/render-vs-railway) - Pricing: [Vercel pricing breakdown](/pricing/vercel) - Best: [Best VPS for Docker workloads](/best/vps-for-docker) - ServerCompass: [Self-host any stack on a VPS in clicks](https://servercompass.app/?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) ## Closing principle If you're agonising over Coolify vs. Kubernetes, the meta-signal is that your scale doesn't require Kubernetes — because at the scale that does, the question doesn't even come up. Take that as a signal to pick the simpler tool, ship more product, and let infrastructure complexity grow when it has to, not when it's interesting. --- **Related in the StoicSoft network** If you're self-hosting on a VPS or working through a deployment guide like the one above, [DeployToVPS](https://deploytovps.com) is the StoicSoft network's handbook for VPS deployment recipes — docker-compose, nginx, traefik, and common app self-hosts. --- ## DigitalOcean Alternatives (2026): Better Value Exists Source: https://deployhandbook.com/blog/alternatives/digitalocean Published: 2026-03-06 DigitalOcean was the value king. Now there are cheaper options with equal or better performance. Here is where to move. DigitalOcean defined "developer-friendly cloud" for a decade. Simple pricing, clean UI, and documentation that actually helped. But the landscape shifted. DigitalOcean is no longer the value leader, and their managed services (App Platform, Managed Databases) are priced like premium products. If you are re-evaluating your hosting, here are the real options. ## Why developers leave DigitalOcean 1. **Pricing is no longer competitive.** A basic Droplet costs $6/month. The same specs on Hetzner cost $4.50 with more bandwidth included. The gap widens at every tier. 2. **Managed services are expensive.** Managed Postgres starts at $15/month for the smallest instance. Self-hosting or using Hetzner's equivalent saves significant money. 3. **App Platform is overpriced.** DigitalOcean's PaaS offering costs more than Railway or Render for similar functionality. 4. **Bandwidth costs add up.** DigitalOcean includes 1TB on basic plans. Hetzner includes 20TB. If your app serves traffic, this matters. ## The comparison table | Option | Best for | Cost signal | Trade-off | |---|---|---|---| | **Hetzner** | raw value, European presence | $4-$50/mo | fewer regions | | **Vultr** | DigitalOcean-like UX, more regions | $5-$60/mo | smaller community | | **Linode (Akamai)** | similar to DO, Akamai network | $5-$60/mo | corporate parent | | **AWS Lightsail** | AWS ecosystem access | $5-$80/mo | less intuitive | | **Self-managed VPS** | maximum control | VPS cost | ops on you | ## Alternative 1: Hetzner (the new value king) Hetzner is what DigitalOcean used to be: aggressive pricing, solid performance, and no-nonsense infrastructure. **Where it wins:** - 30-50% cheaper than DigitalOcean at every tier - 20TB bandwidth included (vs 1TB on DO) - ARM64 servers for even better value - Excellent network performance in EU and US **Where it loses:** - Fewer regions (EU-centric, expanding to US) - UI is functional but not beautiful - Smaller ecosystem of managed add-ons **When to pick it:** - Cost is your primary concern - EU latency works for your users - You are comfortable with basic [server management](https://servercompass.app/features/lock-server) The Hetzner CAX11 (ARM) at $4.50/month outperforms a DigitalOcean $12 droplet for most workloads. The value gap is not small. ## Alternative 2: Vultr (closest DigitalOcean experience) Vultr is the most similar to DigitalOcean in UX and positioning. If you want a swap without adjusting your mental model, Vultr is it. **Where it wins:** - Clean, familiar interface - More regions than Hetzner - Competitive pricing (usually 10-20% less than DO) - Good API and automation support **Where it loses:** - Not as cheap as Hetzner - Support can be slow - Fewer managed service options **When to pick it:** - You want a DigitalOcean-like experience - You need specific regions Hetzner does not cover - You value UI polish ## Alternative 3: Linode (Akamai) Linode was the original "simple cloud" provider. Now owned by Akamai, it has enterprise backing without losing its simplicity. **Where it wins:** - Akamai's network backbone (serious global presence) - Pricing competitive with DigitalOcean - Strong community and documentation - Managed Kubernetes if you need it **Where it loses:** - Corporate ownership brings uncertainty - Fewer innovations recently - UI feels dated compared to newer providers **When to pick it:** - You want enterprise stability - Global CDN integration matters - You have existing Akamai relationships ## Alternative 4: AWS Lightsail (if you might need AWS later) Lightsail is AWS's answer to DigitalOcean: simple, predictable VPS pricing without the AWS complexity. **Where it wins:** - Predictable flat pricing (unlike regular EC2) - Easy path to full AWS services - Global region availability - Native integration with Route 53, S3, etc. **Where it loses:** - AWS complexity leaks through eventually - Support requires paid plans - Less developer-friendly than purpose-built providers **When to pick it:** - You know you will need AWS services eventually - You want to stay in one ecosystem - Your team already knows AWS ## Alternative 5: Stay on DigitalOcean (when it makes sense) DigitalOcean is not bad. It is just no longer the default recommendation. **When to stay:** - You use DigitalOcean Kubernetes (DOKS) heavily - You have significant credits or contracts - Your team knows the platform deeply - You need their specific managed services **When to leave:** - You are paying more than you should for basic compute - Bandwidth overage fees are hitting your bill - You want better value without sacrificing quality ## The VPS migration pattern If you are moving from DigitalOcean to another VPS provider, the pattern is simple: 1. Spin up a new server on target provider 2. Install Docker and your reverse proxy 3. Deploy your stack with [Docker Compose](https://servercompass.app/features/docker-compose-editor) 4. Update DNS to point to new server 5. Verify, then tear down old infrastructure The actual migration takes an afternoon. The cost savings compound monthly. ## Verdict: what I recommend in 2026 **For most teams: Hetzner wins.** The value is not close. You get more compute, more bandwidth, and lower costs. The only real tradeoff is region availability, and that is improving. **If you need more regions:** Vultr is the safe choice with a similar experience to what you know. **If you might scale into AWS:** Start with Lightsail and grow into the full platform. DigitalOcean had a great run as the developer-friendly cloud. That crown now belongs to Hetzner for value and to providers like Railway and Fly for managed simplicity. Know what you need, pay for what you use. ## Where to go next **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) - [VPS Security Setup](https://deploytovps.com/guide/vps-security) **Comparisons:** - [Hetzner vs DigitalOcean](/compare/hetzner-vs-digitalocean) **ServerCompass:** - [Simple deploys on any VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Heroku Alternatives (2026): Escape the Dyno Tax Source: https://deployhandbook.com/blog/alternatives/heroku Published: 2026-03-06 Heroku pricing no longer makes sense for most teams. Here are the best alternatives with real cost comparisons and a clear winner. Heroku was the original "git push to deploy" experience. It shaped how an entire generation thinks about hosting. But in 2026, the math does not work anymore. Heroku's pricing has not kept pace with what you can get elsewhere, and the free tier is long gone. This guide gives you the best paths out, depending on what matters to you. ## Why developers leave Heroku 1. **The dyno tax is real.** A basic dyno costs $7/month. Add a hobby Postgres ($9) and a worker dyno ($7), and you are at $23/month for something you could run on a $6 VPS. 2. **Scaling is expensive.** Standard dynos start at $25 each. Performance dynos are $250+. The moment you need real resources, Heroku becomes one of the most expensive options. 3. **The ecosystem aged.** Heroku was innovative in 2012. In 2026, the deployment primitives (Docker, GitHub Actions, Traefik) are better and free. 4. **Salesforce ownership uncertainty.** Since the Salesforce acquisition, the platform has felt like maintenance mode. Teams worry about long-term investment. ## The comparison table | Option | Best for | Cost signal | Trade-off | |---|---|---|---| | **Railway** | Heroku-like DX, faster iteration | $5-$60/mo | still usage-based | | **Render** | closest Heroku replacement | $7-$85/mo | similar pricing model | | **Fly.io** | global deploys, more control | $5-$40/mo | steeper learning curve | | **Coolify** | self-hosted Heroku feel | VPS cost only | you maintain it | | **VPS + Docker** | predictable cost, full control | $6-$25/mo | you own ops | ## Alternative 1: Railway (best Heroku-like experience) Railway is what Heroku should have become. Fast deploys, clean UI, and a pricing model that at least tries to be fair. **Where it wins:** - [Deploy from GitHub](https://servercompass.app/features/github-repo-deploy) in minutes - Postgres, Redis, and workers are first-class - The UI is modern and fast - Cost is often 30-50% less than equivalent Heroku setup **Where it loses:** - Still usage-based, so costs can creep - No free tier for always-on apps - Less mature ecosystem than Heroku (fewer add-ons) **When to pick it:** - You loved Heroku's workflow but hated the bill - You want to migrate fast without learning new concepts - Your app is small to medium sized ## Alternative 2: Render (closest direct replacement) Render explicitly positions itself as a Heroku alternative. The migration path is straightforward. **Where it wins:** - Heroku-like concepts (web services, background workers, cron) - Native Postgres with automatic backups - Free tier for static sites - [Preview environments](https://servercompass.app/docs/preview-environments) built in **Where it loses:** - Pricing is similar to Heroku at scale - Cold starts on free tier are brutal - Less flexibility than Railway for complex setups **When to pick it:** - You want the easiest possible migration from Heroku - You need preview environments for every PR - Your team is non-technical and needs a simple UI ## Alternative 3: Fly.io (more control, better global performance) Fly is the "graduate" option. More powerful, but requires you to understand a bit more about infrastructure. **Where it wins:** - Multi-region deployment without complexity - Persistent volumes (unlike Heroku's ephemeral filesystem) - Better price-to-performance ratio - Postgres runs on Fly itself (not a separate vendor) **Where it loses:** - CLI-first workflow (less GUI hand-holding) - Documentation assumes some infra knowledge - Debugging requires reading logs and understanding networking **When to pick it:** - You need global latency optimization - You are comfortable with CLI tools - You want persistent storage without external services ## Alternative 4: Coolify (self-hosted Heroku) Coolify gives you a Heroku-like UI on your own server. It is open source and actively maintained. **Where it wins:** - One-click deploys for common stacks - Central dashboard for multiple apps - No per-app pricing, just your server cost - Full data ownership **Where it loses:** - You maintain the platform itself - Upgrades and debugging are on you - Smaller community than commercial options **When to pick it:** - You want the Heroku experience without Heroku pricing - You are comfortable maintaining your own infrastructure - You have multiple apps that would cost too much on Heroku ## Alternative 5: VPS + Docker (the value winner) This is the boring answer. Boring wins in hosting. A typical setup: - Hetzner CX22 ($6/mo) or CX32 ($12/mo) - Docker + [Docker Compose](https://servercompass.app/features/docker-compose-editor) - Traefik for reverse proxy and automatic HTTPS - GitHub Actions for CI/CD **Where it wins:** - Flat, predictable monthly cost - Run 5+ apps on a single server - No vendor lock-in - Full control over runtime and networking **Where it loses:** - Initial learning curve (one day to set up properly) - You must handle backups and monitoring - No "click to scale" option **When to pick it:** - Your Heroku bill is your main pain point - You have stable, predictable traffic - You want to consolidate multiple services ## Verdict: what I recommend in 2026 For most teams leaving Heroku: **Start with Railway** if you want the fastest migration with minimal learning. It is the closest thing to "Heroku but better" and will cut your bill immediately. **Move to a VPS** when you have stable traffic and you are ready to own your infrastructure. The cost difference is dramatic: what costs $50-100/month on Heroku or Railway costs $6-20/month on a VPS. Heroku made deployment easy for a generation of developers. That generation now knows enough to run their own servers. The training wheels can come off. ## Where to go next **Tutorials:** - [Deploy Node.js to VPS](https://deploytovps.com/deploy/nodejs) - [Self-Host Postgres](https://deploytovps.com/self-host/postgres) **Comparisons:** - [Railway vs Render](/compare/railway-vs-render) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Netlify Alternatives (2026): What to Use Instead Source: https://deployhandbook.com/blog/alternatives/netlify Published: 2026-03-06 A quick, honest set of Netlify alternatives for teams that outgrow static-first hosting or want more predictable pricing. Netlify is great at what it is built for: a static-first workflow with a strong developer experience. Teams leave Netlify when: - their product stops being "just static" - they add background jobs and databases - they need more control over networking and performance - they want a single place to run both frontend and backend without stacking vendors This guide gives you the best replacements depending on what you are building. ## The short list | Alternative | Best for | Tradeoff | |---|---|---| | Vercel | Next.js-centric apps | usage pricing can bite | | Railway | backends + quick deploy | not a frontend edge platform | | Fly.io | control + multi-region | more ops than Netlify | | VPS | predictable cost | you own ops | | Self-hosted PaaS (Coolify/Dokploy) | UI for multiple apps | maintenance overhead | ## Option 1: Vercel (if your app is Next.js-heavy) If Netlify is your static host and your app is gradually becoming a full product, Vercel is usually the fastest upgrade path, especially for Next.js. The reason teams eventually leave Vercel is the same reason they leave Netlify: At some point you want cost predictability and control. ## Option 2: Railway (if you really need a backend platform) Railway is not a Netlify replacement. It is a backend deploy platform. Pick it when: - your frontend can live on a CDN - your main pain is deploying an API and a database quickly ## Option 3: Fly.io (if you want "infra but not a raw VPS") Fly is a good choice if you are ready to learn a little infra and you want to avoid managing a server directly. It is especially good for: - latency-sensitive apps - global routing ## Option 4: VPS (the value winner when your product is real) When your app becomes real, a VPS becomes attractive because: - cost is mostly flat - you can host multiple services - you control the entire runtime The tradeoff is that you need a repeatable deployment workflow. Without that, your VPS turns into "snowflake server" territory. If you want the "Vercel-like" workflow on your VPS, start here: https://servercompass.app/compare/netlify?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta ## Where to go next (internal links) - Tutorials: - `/deploy/astro` - `/deploy/nextjs` - Comparison: - `/compare/railway-vs-render` - ServerCompass: - https://servercompass.app/compare/netlify?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta --- **Related in the StoicSoft network** If you're self-hosting on a VPS or working through a deployment guide like the one above, [DeployToVPS](https://deploytovps.com) is the StoicSoft network's handbook for VPS deployment recipes — docker-compose, nginx, traefik, and common app self-hosts. --- ## Railway Alternatives (2026): Cheaper Deploys Without Losing Speed Source: https://deployhandbook.com/blog/alternatives/railway Published: 2026-03-06 Railway is fast, but the bill grows with every service. These are the best Railway alternatives depending on whether you want cost, control, or simplicity. Railway is excellent for the first month of a project. It gets you from code to production with almost no friction. Then the project becomes real: - you add a worker - you add a staging environment - you add a second database Suddenly your bill looks like a platform bill, not "just hosting". This guide gives you the best replacements depending on what you actually want. ## Why developers leave Railway Teams leave Railway when: - they run more than a couple always-on services - they need more control over networking and deployment architecture - the database becomes a meaningful cost center - they want one flat-cost place to run everything ## The comparison table | Alternative | Best for | What you trade | |---|---|---| | Render | similar PaaS feel | still a platform bill | | Fly.io | control + multi-region | more ops | | VPS | flat cost, full control | you own ops | | Self-hosted PaaS (Coolify/Dokploy) | UI on top of VPS | maintenance | | ServerCompass | Vercel-like workflows on VPS | tool cost | ## Option 1: Render (closest "swap" for Railway) Render is a reasonable "same category" alternative. Pick it if: - you like PaaS workflows - you accept that you will pay more for convenience If you are choosing between Railway and Render specifically, read: https://servercompass.app/compare/render?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta ## Option 2: Fly.io (if you are ready for more control) Fly is often the best "graduate" step: - not fully DIY - more portable architecture - less vendor lock-in It is not as simple as Railway, but it is usually the sweet spot for teams who want more control. ## Option 3: VPS (the value winner) If your primary goal is cost predictability, a VPS wins. A realistic starter setup: - 1 VPS (Hetzner is the common value pick) - [Docker Compose](https://servercompass.app/features/docker-compose-editor) - reverse proxy (Traefik/Nginx) - backups and monitoring The difference is not just cost. The difference is that you can host: - web app - API - worker - cron - database (if you choose) all on one bill. If you want to keep the "push to deploy" feel while moving to a VPS, compare: https://servercompass.app/compare/railway?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta ## Where to go next (internal links) - Tutorials: - `/deploy/nodejs` - `/guide/github-actions-vps` - Comparison: - `/compare/railway-vs-render` - ServerCompass: - https://servercompass.app/compare/railway?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta --- **Related in the StoicSoft network** If you're self-hosting on a VPS or working through a deployment guide like the one above, [DeployToVPS](https://deploytovps.com) is the StoicSoft network's handbook for VPS deployment recipes — docker-compose, nginx, traefik, and common app self-hosts. --- ## Render Alternatives (2026): When the Free Tier Stops Working Source: https://deployhandbook.com/blog/alternatives/render Published: 2026-03-06 Render is solid until you scale. Here are the best alternatives when cold starts and pricing push you to look elsewhere. Render built a good product. Clean UI, straightforward deploys, and a free tier that actually lets you run something. Then your app gets traffic: - The free tier spins down after 15 minutes of inactivity - Cold starts add 30+ seconds to the first request - Paid tiers jump quickly once you add workers and databases This guide covers your options when Render stops being the right fit. ## Why developers leave Render 1. **Cold starts kill user experience.** The free tier is only free if you do not mind your users waiting half a minute for the first request. This is fine for demos, terrible for products. 2. **Pricing jumps are steep.** Free to $7/month is fine. But adding a background worker ($7), a cron job ($1), and Postgres ($7) means you are suddenly at $22/month for a basic app. 3. **Limited control over infrastructure.** Render abstracts away the server. That is great until you need persistent volumes, custom networking, or specific runtime configurations. 4. **[Preview environments](https://servercompass.app/docs/preview-environments) cost money.** Unlike some competitors, Render charges for preview environment resources. PR-based deploys add up. ## The comparison table | Option | Best for | Cost signal | Trade-off | |---|---|---|---| | **Railway** | similar DX, better iteration speed | $5-$60/mo | still usage-based | | **Fly.io** | no cold starts, global presence | $5-$40/mo | more CLI-focused | | **Coolify** | self-hosted with UI | VPS cost | maintenance overhead | | **VPS + Docker** | flat cost, full control | $6-$25/mo | ops ownership | | **Vercel** | frontend-heavy apps | $20-$100/mo | backend is an afterthought | ## Alternative 1: Railway (fastest switch) Railway and Render compete directly. The migration is usually straightforward. **Where it wins:** - No cold starts on paid plans - Better real-time logs and debugging - Cleaner environment variable management - Usage-based means you pay for what you use **Where it loses:** - No free tier for always-on services - Usage pricing can surprise you - Smaller ecosystem than Render **When to pick it:** - Cold starts are your main Render frustration - You want a quick swap without learning new concepts - Your app is backend-heavy (APIs, workers) ## Alternative 2: Fly.io (best performance upgrade) Fly is what you pick when you realize you want more control than a PaaS gives you, but you are not ready for raw VPS management. **Where it wins:** - No cold starts, ever - Multi-region deployment is built-in - Persistent volumes for file storage - Better price-to-performance than Render at scale **Where it loses:** - CLI-first workflow takes adjustment - More concepts to learn (machines, volumes, networking) - Less hand-holding in the UI **When to pick it:** - Performance matters to your users - You want global latency optimization - You are comfortable with terminal workflows ## Alternative 3: Coolify (self-hosted Render) Coolify gives you a Render-like dashboard on your own VPS. You get the UI convenience without the per-service billing. **Where it wins:** - No per-app costs, just server cost - Deploy unlimited apps from one dashboard - Full control over resources - Active development and community **Where it loses:** - You maintain the control panel - Upgrades and security patches are your job - Smaller feature set than Render **When to pick it:** - You have multiple apps bleeding you dry on Render - You want a UI but not the Render bill - You can commit to light maintenance work ## Alternative 4: VPS + Docker (the value winner) When cost predictability is the goal, a VPS beats every PaaS. A solid setup: - Hetzner VPS (CX22 at $6/mo handles most small apps) - [Docker Compose](https://servercompass.app/features/docker-compose-editor) for service orchestration - Traefik or Nginx for reverse proxy - Let's Encrypt for automatic HTTPS **Where it wins:** - Fixed monthly cost regardless of traffic - Run your web app, API, worker, and database on one server - No cold starts, no spin-downs - Complete control over everything **Where it loses:** - Setup takes a few hours the first time - You handle backups and monitoring - No "click to add region" button **When to pick it:** - Your Render bill is the problem - You have predictable traffic patterns - You want to stop thinking about per-service pricing ## Alternative 5: Vercel (if your app is mostly frontend) If your Render app is really a Next.js frontend with some API routes, Vercel might be the better fit. **Where it wins:** - Best-in-class frontend deployment - Edge functions for global performance - Preview deployments on every PR **Where it loses:** - Backends are second-class citizens - Usage pricing can spike unexpectedly - Not great for workers, crons, or heavy API loads **When to pick it:** - Your app is 80%+ frontend - You use Next.js or a similar framework - API routes are simple and stateless ## Verdict: what I recommend in 2026 **If cold starts are your pain:** Move to Fly.io. It solves the problem directly and gives you a path to grow. **If cost is your pain:** Move to a VPS. The math is simple: what costs $30-50/month on Render costs $6-15/month on a VPS. **If you just want a quick swap:** Railway is the easiest migration. Similar concepts, slightly better execution. Render is not bad. It is just positioned in a middle ground that gets squeezed from both sides: cheaper VPS options below, more powerful platforms above. Know what you actually need, then pick accordingly. ## Where to go next **Tutorials:** - [Deploy Docker Compose to VPS](https://deploytovps.com/deploy/docker-compose) - [Traefik SSL Setup](https://deploytovps.com/guide/traefik-ssl) **Comparisons:** - [Railway vs Render](/compare/railway-vs-render) **ServerCompass:** - [Render-like deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Vercel Alternatives (2026): Pay Less, Keep Speed Source: https://deployhandbook.com/blog/alternatives/vercel Published: 2026-03-06 A practical shortlist of Vercel alternatives with real cost envelopes, when to switch, and the clear winner for most teams after the prototype phase. If your Vercel bill is creeping up, it is not because you did something wrong. Vercel is designed to feel frictionless, and frictionless usually costs more than you expect once you have real traffic, real builds, and more than one environment. This guide is opinionated on purpose. You are not here for "it depends". You are here to pick a path that keeps your deploy speed while making your cost predictable. ## Why developers leave Vercel Most teams leave Vercel for one of these reasons: 1. **Usage pricing becomes a second job.** Bandwidth, edge/function invocations, build minutes, image optimization, logs. Each line item is fine until you have three of them at once. 2. **Backends become "outside of Vercel".** The moment you add Postgres, Redis, background jobs, and queues, you are already running a platform, just spread across vendors. 3. **You want control and portability.** You can absolutely run Next.js elsewhere. The hard part is not "can it run". The hard part is the boring infrastructure glue (TLS, reverse proxy, rollbacks, deployments). ## The comparison table (fast shortlist) | Option | Best for | What you trade | Cost signal | |---|---|---|---| | **Railway** | small backends, prototypes | less edge magic, more app-first | $15 to $60+ | | **Fly.io** | global latency, "infra but not a VPS" | more ops than Vercel | $10 to $50 | | **Coolify** | DIY platform on a server | time, maintenance, upgrades | server cost + time | | **Dokploy** | simpler self-hosted deploy UI | smaller ecosystem | server cost + time | | **Self-hosted VPS** | predictable cost, stable traffic | you own the ops | $6 to $25 | | **ServerCompass** | Vercel-like workflows on your VPS | one-time tool cost | VPS cost + tool | If you want the simplest rule: - If you have **one app** and you are still iterating, Vercel is fine. - If you have **multiple services** or you care about monthly predictability, move to **a VPS-based stack**. ## Alternative 1: Railway (good for backends, mediocre for "Vercel replacement") Railway is a strong "deploy my backend" platform. For many teams it is the first stop after Vercel, because it keeps the "push to deploy" feeling. Where Railway wins: - You can [deploy a Node](https://servercompass.app/blog/how-to-deploy-nodejs-app-on-vps) app plus Postgres in minutes. - The UI is straightforward. - The cost is more predictable than Vercel for backend-heavy workloads. Where Railway loses: - If your app is front-end heavy, Railway does not replicate the Vercel edge ecosystem. - You still end up stitching together DNS, proxy, and background jobs as you grow. When to pick Railway: - Your main pain is **deploying a backend** (APIs, workers, cron). - You are okay with platform pricing in exchange for speed. ## Alternative 2: Fly.io (best "middle ground" if you are comfortable with infra) Fly.io is often the best "I want more control than Vercel, but I do not want to babysit a VPS" option. Fly wins when: - You want multi-region latency without designing it all yourself. - You can read logs, understand deploy config, and tolerate a bit more setup. Fly loses when: - You want the simplest possible experience. - You are trying to avoid learning the basics of networking, TLS, and resource sizing. Cost reality check: Fly can be cheap, but bandwidth and storage are where teams get surprised. It is still typically less chaotic than the Vercel usage soup once you scale. ## Alternative 3: Coolify (self-hosted PaaS if you can commit to maintenance) Coolify is popular because it looks like "run your own Heroku". It can be great, but it is not free. You pay with time. Coolify wins when: - You want a central UI for multiple apps on one server. - You are comfortable owning upgrades and debugging. Coolify loses when: - You want boring reliability without being on call for your own control panel. If you pick Coolify, treat it like production software you must maintain: backups, upgrades, monitoring, and a rollback plan. ## Alternative 4: Dokploy (simpler self-hosted deploy UI) Dokploy tends to appeal to teams who want: - a lighter UI - a smaller surface area - fewer "platform" concepts It is usually a good fit if you are already set on a VPS and want a UI, not another vendor. ## Alternative 5: Self-hosted VPS (the value winner for most teams) This is the boring answer, and boring is what you want for hosting. The typical "starter" VPS path looks like: - **Hetzner** (or similar) for predictable compute cost - Docker + [Docker Compose](https://servercompass.app/features/docker-compose-editor) - a reverse proxy (Traefik or Nginx) - backups (volume snapshots + DB dumps) Why it wins: - Your cost becomes mostly **flat**. - You can host multiple services on one server. - You are not locked into a vendor runtime. What you must accept: - You will spend a day learning the setup the first time. - You must have a recovery plan (backups + how to redeploy). If you are allergic to ops, do not do this. But if your bill matters, this is the strongest long-term move. ## Alternative 6: ServerCompass (Vercel-like deploys on a VPS) ServerCompass exists for a very specific pain: You want the predictable cost of a VPS, but you do not want to rebuild the same deployment glue for every app. If that is you, start here: - ServerCompass vs Vercel: https://servercompass.app/compare/vercel?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta ## Verdict: what I recommend in 2026 If you are paying meaningful money on Vercel and your app is not a pure static marketing site, the winner is: **Self-hosted VPS, with a deployment workflow you can repeat.** Vercel stays excellent for prototypes and fast iteration. But for most teams, the moment you have stable traffic and more than one service, a VPS wins on budget and control. ## Where to go next (internal links) - Tutorials: - `/deploy/nextjs` (Deploy Next.js to a VPS) - `/self-host/supabase` (Self-host Supabase) - Comparison: - `/compare/railway-vs-render` - ServerCompass: - https://servercompass.app/compare/vercel?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta --- **Related in the StoicSoft network** If you're self-hosting on a VPS or working through a deployment guide like the one above, [DeployToVPS](https://deploytovps.com) is the StoicSoft network's handbook for VPS deployment recipes — docker-compose, nginx, traefik, and common app self-hosts. --- ## Best Cheap VPS for Developers (2026): Hetzner, DigitalOcean, Vultr, Linode Source: https://deployhandbook.com/blog/best/cheap-vps-hosting Published: 2026-03-06 A practical comparison of budget VPS providers for developers. Real specs, real prices, and clear recommendations. A good VPS is the foundation of cost-effective hosting. One server at $6-12/month can replace $100+/month in PaaS costs. This is a practical comparison of the best budget VPS options for developers in 2026. ## Quick Comparison Table | Provider | Entry Price | Best Value Tier | Bandwidth | Regions | Best For | |----------|-------------|-----------------|-----------|---------|----------| | **Hetzner** | $4.35/mo | CX32 ($7.59) | 20TB | EU, US | Best value | | **DigitalOcean** | $6/mo | $12/mo | 2TB | Global | Simplicity | | **Vultr** | $6/mo | $12/mo | 2TB | Global | Flexibility | | **Linode** | $5/mo | $12/mo | 2TB | Global | Reliability | ## The Winner: Hetzner For pure price-to-performance, Hetzner wins. The specs and bandwidth are significantly better than US competitors at the same price. **However:** If you need US-based servers with more datacenter options, DigitalOcean or Vultr are solid choices. ## Hetzner Cloud Hetzner is the European provider that US developers discovered. The value is hard to beat. **Pricing:** | Instance | vCPU | RAM | Storage | Price | |----------|------|-----|---------|-------| | CX22 | 2 | 4 GB | 40 GB | $4.35/mo | | CX32 | 4 | 8 GB | 80 GB | $7.59/mo | | CX42 | 8 | 16 GB | 160 GB | $14.49/mo | **Strengths:** - Best specs per dollar - 20TB bandwidth included (competitors offer 2-4TB) - Clean, fast control panel - Reliable uptime - US datacenter in Ashburn, VA **Weaknesses:** - Fewer datacenter locations than competitors - Less "ecosystem" (managed databases, etc.) - Support is functional, not premium **Best for:** - Cost-conscious developers - High-bandwidth applications - European-focused projects ## DigitalOcean DigitalOcean pioneered developer-friendly VPS. Still a solid choice, just not the cheapest. **Pricing:** | Instance | vCPU | RAM | Storage | Price | |----------|------|-----|---------|-------| | Basic | 1 | 1 GB | 25 GB | $6/mo | | Basic | 1 | 2 GB | 50 GB | $12/mo | | Basic | 2 | 4 GB | 80 GB | $24/mo | **Strengths:** - Excellent documentation - Large ecosystem (managed databases, Kubernetes, app platform) - Many datacenter locations - Good community and tutorials - Reliable and well-established **Weaknesses:** - More expensive than Hetzner for same specs - 2TB bandwidth vs Hetzner's 20TB - Pricing has crept up over the years **Best for:** - Developers who value ecosystem and docs - Projects needing managed add-ons - Teams already familiar with DO ## Vultr Vultr is the flexible middle ground. Competitive pricing with global reach. **Pricing:** | Instance | vCPU | RAM | Storage | Price | |----------|------|-----|---------|-------| | Cloud Compute | 1 | 1 GB | 25 GB | $6/mo | | Cloud Compute | 1 | 2 GB | 55 GB | $12/mo | | Cloud Compute | 2 | 4 GB | 80 GB | $24/mo | **Strengths:** - 32 datacenter locations worldwide - Hourly billing - Good API - Bare metal options - Competitive pricing **Weaknesses:** - Less polished than DigitalOcean - Smaller community - Documentation is adequate, not great **Best for:** - Global deployments needing many regions - Developers who want flexibility - Projects needing bare metal ## Linode (Akamai) Linode was acquired by Akamai but maintains its developer focus. Reliable and straightforward. **Pricing:** | Instance | vCPU | RAM | Storage | Price | |----------|------|-----|---------|-------| | Nanode | 1 | 1 GB | 25 GB | $5/mo | | Linode 2GB | 1 | 2 GB | 50 GB | $12/mo | | Linode 4GB | 2 | 4 GB | 80 GB | $24/mo | **Strengths:** - Long track record of reliability - Good support reputation - Straightforward pricing - Akamai CDN integration **Weaknesses:** - Similar pricing to DigitalOcean (more expensive than Hetzner) - Fewer managed services than DO - Interface feels less modern **Best for:** - Teams prioritizing reliability over cost - Long-term projects needing stable provider - Akamai CDN users ## Detailed Feature Comparison | Feature | Hetzner | DigitalOcean | Vultr | Linode | |---------|---------|--------------|-------|--------| | Entry price | $4.35 | $6 | $6 | $5 | | 4GB RAM tier | $4.35 | $24 | $24 | $24 | | 8GB RAM tier | $7.59 | $48 | $48 | $48 | | Bandwidth | 20TB | 2-4TB | 2-3TB | 2-4TB | | Datacenter count | 5 | 15 | 32 | 11 | | Managed DB | No | Yes | Yes | Yes | | Kubernetes | No | Yes | Yes | Yes | | API quality | Good | Excellent | Good | Good | | Docs quality | Good | Excellent | Adequate | Good | ## Real Cost Examples ### Side project (blog, portfolio, small app) | Provider | Instance | Monthly | |----------|----------|---------| | Hetzner | CX22 | $4.35 | | DigitalOcean | Basic 1GB | $6 | | Vultr | Cloud 1GB | $6 | | Linode | Nanode | $5 | **Winner:** Hetzner at $4.35 for 2 vCPU, 4GB RAM ### Small SaaS (API, database, workers) | Provider | Instance | Monthly | |----------|----------|---------| | Hetzner | CX32 | $7.59 | | DigitalOcean | Basic 4GB | $24 | | Vultr | Cloud 4GB | $24 | | Linode | Linode 4GB | $24 | **Winner:** Hetzner at $7.59 for 4 vCPU, 8GB RAM ### Growing startup (production workload) | Provider | Instance | Monthly | |----------|----------|---------| | Hetzner | CX42 | $14.49 | | DigitalOcean | Basic 8GB | $48 | | Vultr | Cloud 8GB | $48 | | Linode | Linode 8GB | $48 | **Winner:** Hetzner at $14.49 for 8 vCPU, 16GB RAM ## My Recommendation **For most developers:** Start with **Hetzner**. The value is unmatched. A CX32 at $7.59/mo gives you 4 vCPU and 8GB RAM, which costs $48/mo at competitors. **If you need US presence:** Hetzner has an Ashburn, VA datacenter. If you need West Coast or more US options, consider **Vultr** for region flexibility or **DigitalOcean** for ecosystem. **If you want managed services:** **DigitalOcean** has the best ecosystem. Managed databases, Kubernetes, and App Platform are useful if you want less DIY. **For reliability focus:** **Linode** has the longest track record. If stability matters more than cost optimization, it is a safe choice. ## Getting Started 1. Create an account at your chosen provider 2. Spin up the smallest instance that fits your needs 3. Install Docker: `curl -fsSL https://get.docker.com | sh` 4. Deploy with [Docker Compose](https://servercompass.app/features/docker-compose-editor) or a self-hosted PaaS Most developers are running production apps within an hour. ## Where to go next **Pricing:** - [Hetzner Pricing](/pricing/hetzner) **Comparisons:** - [Hetzner vs DigitalOcean](/compare/hetzner-vs-digitalocean) **Best of:** - [Best Self-Hosted PaaS](/best/self-hosted-paas) **Tutorials:** - [Deploy to VPS with Docker](https://deploytovps.com/deploy/docker) **ServerCompass:** - [One-click deploys on any VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Best Self-Hosted PaaS (2026): Coolify, Dokploy, CapRover, ServerCompass Source: https://deployhandbook.com/blog/best/self-hosted-paas Published: 2026-03-06 A practical comparison of self-hosted PaaS options. Run your own Heroku alternative on a VPS for a fraction of the cost. Self-hosted PaaS gives you the deployment experience of Heroku or Railway on your own infrastructure. One VPS, flat monthly cost, unlimited apps. This is a practical comparison of the four best options in 2026. ## Quick Comparison Table | Platform | Best For | Learning Curve | App Templates | Active Development | |----------|----------|----------------|---------------|-------------------| | **Coolify** | Most teams | Medium | 150+ | Very active | | **Dokploy** | Minimalists | Low | 50+ | Active | | **CapRover** | Docker veterans | Medium-High | 100+ | Stable | | **ServerCompass** | Repeatable deploys | Low | Focused | Active | ## The Winner: It Depends on Your Style - **Best overall**: Coolify - most polished, largest template library - **Best for simplicity**: Dokploy - cleaner UI, fewer options - **Best for Docker experts**: CapRover - most configurable - **Best for teams**: ServerCompass - built for repeatable workflows ## Coolify Coolify is the most feature-complete self-hosted PaaS. Think of it as "Vercel that runs on your server." **Strengths:** - 150+ one-click app templates (databases, apps, tools) - Git-based deployments with automatic builds - Built-in SSL via Let's Encrypt - Docker and Docker Compose support - Active development with frequent updates - Good documentation **Weaknesses:** - Resource overhead (runs multiple containers for management) - UI can feel overwhelming with many options - Occasional bugs on edge cases **Best for:** - Teams wanting a full-featured self-hosted platform - Developers who want Vercel/Railway UX on their own hardware - Projects that need many different services **Minimum server:** 2 vCPU, 4GB RAM (8GB recommended) **Setup time:** 15-30 minutes ```bash curl -fsSL https://cdn.coollabs.io/coolify/install.sh | bash ``` ## Dokploy Dokploy is the minimalist alternative to Coolify. Fewer features, cleaner experience. **Strengths:** - Clean, simple UI - Lower resource footprint than Coolify - Docker and Docker Compose support - Git integration with webhooks - Fast setup **Weaknesses:** - Fewer app templates than Coolify - Smaller community - Less documentation **Best for:** - Developers who find Coolify overwhelming - Simple deployments without many bells and whistles - Resource-constrained servers **Minimum server:** 1 vCPU, 2GB RAM (4GB recommended) **Setup time:** 10-20 minutes ```bash curl -sSL https://dokploy.com/install.sh | sh ``` ## CapRover CapRover is the veteran in self-hosted PaaS. Battle-tested but showing its age. **Strengths:** - Proven and stable - Large template library - Cluster support for multi-server deployments - Strong Docker integration - Detailed documentation **Weaknesses:** - UI feels dated compared to newer options - More complex initial setup - Slower development pace - Requires more Docker knowledge **Best for:** - Docker experts who want maximum control - Production workloads that need stability over features - Multi-server cluster deployments **Minimum server:** 1 vCPU, 1GB RAM (2GB recommended) **Setup time:** 20-40 minutes ```bash docker run -p 80:80 -p 443:443 -p 3000:3000 \ -v /var/run/docker.sock:/var/run/docker.sock \ -v /captain:/captain \ caprover/caprover ``` ## ServerCompass ServerCompass focuses on repeatable, team-friendly deployments rather than being a full PaaS. **Strengths:** - Built for repeatable workflows - Team collaboration features - Clear [deployment history](https://servercompass.app/features/deployment-history) - Less cognitive overhead than full PaaS - Focused feature set **Weaknesses:** - Fewer templates than Coolify - Newer project, smaller community - Less suited for "deploy everything" use cases **Best for:** - Teams with established deployment patterns - Developers who want consistency over flexibility - Projects that need clear deployment audit trails **Minimum server:** 2 vCPU, 4GB RAM **Setup time:** 10-15 minutes ## Detailed Feature Comparison | Feature | Coolify | Dokploy | CapRover | ServerCompass | |---------|---------|---------|----------|---------------| | One-click apps | 150+ | 50+ | 100+ | Focused | | Git deployments | Yes | Yes | Yes | Yes | | Docker Compose | Yes | Yes | Limited | Yes | | [SSL certificates](https://servercompass.app/docs/ssl-certificates) | Auto | Auto | Auto | Auto | | Database backups | Yes | Yes | Manual | Yes | | Team features | Yes | Basic | Basic | Yes | | Multi-server | Yes | No | Yes | Planned | | Resource usage | Higher | Lower | Medium | Medium | | UI polish | Good | Good | Dated | Good | ## Cost Comparison All options are free and open source. Your only cost is the VPS. | VPS Size | Monthly Cost | Can Run | |----------|--------------|---------| | 2 vCPU, 4GB | $6-12 | Dokploy, CapRover | | 4 vCPU, 8GB | $12-20 | All options comfortably | | 8 vCPU, 16GB | $20-35 | All options + multiple apps | Compare this to: - Vercel Pro: $20/seat/month - Railway: $15-60/month - Render: $50-150/month A self-hosted PaaS on a $12 VPS replaces $100+/month in managed hosting. ## My Recommendation **For most developers:** Start with **Coolify**. It has the best balance of features, community, and polish. The resource overhead is worth it for the capability. **For simpler needs:** Try **Dokploy**. If you deploy 2-5 apps and do not need advanced features, the cleaner UI is refreshing. **For Docker experts:** **CapRover** gives you the most control if you are comfortable with Docker and want stability over new features. **For teams:** **ServerCompass** is worth evaluating if you need repeatable workflows and deployment consistency across team members. ## Getting Started 1. Spin up a VPS (Hetzner CX32 at $7.59/mo is excellent value) 2. Point a domain to your server IP 3. Run the install script for your chosen platform 4. [Deploy your first app](https://servercompass.app/docs/quick-start-deploy) Most teams are running production workloads within an hour. ## Where to go next **Tutorials:** - [Self-host Supabase](https://deploytovps.com/self-host/supabase) - [Deploy with Docker Compose](https://deploytovps.com/deploy/docker-compose) **Comparisons:** - [Coolify vs Dokploy](/compare/coolify-vs-dokploy) - [Coolify vs ServerCompass](/compare/coolify-vs-servercompass) **Pricing:** - [Hetzner Pricing](/pricing/hetzner) **ServerCompass:** - [Try ServerCompass](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## CapRover vs Coolify: Self-Hosted PaaS Comparison Source: https://deployhandbook.com/blog/compare/caprover-vs-coolify Published: 2026-03-06 Head-to-head comparison for developers choosing between CapRover and Coolify for self-hosted deployments. **Quick answer:** Pick Coolify if you want a modern UI, active development, and simpler single-server deployments. Pick CapRover if you need Docker Swarm clustering out of the box. ## Comparison Table | Criteria | CapRover | Coolify | |----------|----------|---------| | **Architecture** | Docker Swarm native | [Docker Compose](https://servercompass.app/features/docker-compose-editor) + Swarm support | | **UI/UX** | Functional, dated | Modern, polished | | **Development pace** | Slower, stable | Active, frequent updates | | **One-click apps** | Large template library | Growing template library | | **Multi-server** | Native Swarm clustering | Supported but newer | | **Learning curve** | Medium | Easy to Medium | | **Verdict** | Best for clusters | Best for single servers | ## CapRover Overview ### Strengths - Mature Docker Swarm integration - Proven for multi-node clusters - Large one-click app template library - Automatic SSL with Let's Encrypt - Simple Dockerfile-based deployments ### Weaknesses - UI feels dated compared to modern tools - Development pace has slowed - Documentation could be more comprehensive - Less active community engagement - Some features feel abandoned ### Best for - Teams already [using Docker](https://servercompass.app/blog/deploy-apps-vps-docker-compose) Swarm - Multi-server cluster deployments - Projects needing proven stability - Developers familiar with older PaaS patterns ## Coolify Overview ### Strengths - Modern, clean user interface - Very active development and community - Simple single-server setup - Git-based deployments with webhooks - Good Docker Compose support ### Weaknesses - Younger project, still maturing - Multi-server support less battle-tested - Breaking changes between versions - Smaller (but growing) template library - Some advanced features still in development ### Best for - Single-[server self-hosted](https://servercompass.app/templates/sql-server) deployments - Teams wanting modern tooling - Projects that value active maintenance - Developers new to self-hosted PaaS ## When to pick CapRover Pick CapRover if: - You need Docker Swarm clustering today - Multi-node high availability is required - You prefer proven, stable software - Your team is familiar with Swarm concepts - You want a large template library immediately ## When to pick Coolify Pick Coolify if: - You are deploying to a single server - Modern UI and UX matter to you - You want active development and updates - You prefer Docker Compose workflows - You value community engagement and support ## Verdict Coolify is the better choice for most developers in 2026. The active development, modern interface, and simpler setup make it easier to adopt. For single-server deployments, Coolify provides everything you need with less friction. CapRover remains the stronger choice if you specifically need Docker Swarm clustering across multiple nodes. It is more mature for that use case, even if the UI and development pace lag behind. For teams wanting even more control with less abstraction, consider ServerCompass or a pure Docker Compose setup on your VPS. ## Where to go next **Tutorials:** - [Self-Host Coolify](https://deploytovps.com/self-host/coolify) - [Deploy Docker Compose to VPS](https://deploytovps.com/deploy/docker-compose) **Related comparisons:** - [Coolify vs Dokploy](/compare/coolify-vs-dokploy) - [Coolify vs ServerCompass](/compare/coolify-vs-servercompass) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Coolify vs Dokploy: Self-Hosted PaaS Comparison Source: https://deployhandbook.com/blog/compare/coolify-vs-dokploy Published: 2026-03-06 Both let you run your own Heroku. Which one should you pick for your VPS? **Quick answer:** **Coolify** is the more mature option with better app templates and a larger community. **Dokploy** is simpler and lighter if you want minimal overhead. ## Comparison Table | Criteria | Coolify | Dokploy | |----------|---------|---------| | **Maturity** | 3+ years, v4 stable | Newer, rapidly developing | | **App templates** | 100+ one-click apps | Growing catalog | | **Docker support** | Full [Docker Compose](https://servercompass.app/features/docker-compose-editor) | Docker Compose | | **Git integration** | GitHub, GitLab, Bitbucket | GitHub, GitLab | | **[SSL certificates](https://servercompass.app/docs/ssl-certificates)** | Let's Encrypt auto | Let's Encrypt auto | | **[Database management](https://servercompass.app/features/data-import)** | Built-in PostgreSQL, MySQL, etc. | Docker-based | | **Team features** | Multi-user, permissions | Basic multi-user | | **Resource usage** | ~500MB RAM | ~200MB RAM | | **Open source** | Yes (AGPL) | Yes (MIT) | ## Coolify Overview Coolify positions itself as a "self-hosted Heroku/Netlify alternative." It's been around longer and has more features. ### Strengths - **Mature and stable.** Version 4 is production-ready with years of development behind it. - **Rich app catalog.** Over 100 one-click deployable applications. - **Better database management.** Built-in support for creating and managing databases. - **Active community.** Larger Discord, more GitHub activity, better documentation. - **Webhooks and notifications.** Slack, Discord, email notifications built-in. ### Weaknesses - **Higher resource usage.** Needs more RAM to run comfortably (~500MB+). - **More complex.** More features means more to learn and configure. - **AGPL license.** Some teams prefer MIT for legal simplicity. ### Best for - Teams that want a full-featured PaaS experience - Projects needing many one-click apps - Users who value community and documentation ## Dokploy Overview Dokploy is a newer, lighter alternative focused on simplicity. ### Strengths - **Lightweight.** Uses less RAM and CPU than Coolify. - **Simpler interface.** Fewer features, but easier to understand. - **MIT licensed.** More permissive for commercial use. - **Fast iteration.** Actively developed with frequent updates. ### Weaknesses - **Smaller ecosystem.** Fewer one-click apps and integrations. - **Less mature.** Newer project, still evolving. - **Smaller community.** Less documentation and community support. ### Best for - Developers who want minimal overhead - Smaller projects with simpler needs - Those who prefer MIT-licensed software ## When to Pick Coolify Pick Coolify if: - You want the most mature self-hosted PaaS option - You need a large catalog of one-click apps - You value community support and documentation - You need team features with permissions ## When to Pick Dokploy Pick Dokploy if: - You want a lighter, simpler solution - You're running on a smaller VPS - You prefer MIT licensing - You only need basic deployment features ## Verdict **Coolify is the winner for most teams.** It's more mature, has better app templates, and a larger community. The extra resource usage is worth it for the features and stability. Pick Dokploy if you specifically need something lighter or prefer the simpler approach. ## Where to go next **Tutorials:** - [Self-Host Supabase](https://deploytovps.com/self-host/supabase) - [Deploy Docker to VPS](https://deploytovps.com/deploy/docker) **Related comparisons:** - [Coolify vs ServerCompass](/compare/coolify-vs-servercompass) - [Best Self-Hosted PaaS](/best/self-hosted-paas) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Coolify vs ServerCompass: Different Approaches to VPS Deployment Source: https://deployhandbook.com/blog/compare/coolify-vs-servercompass Published: 2026-03-06 Coolify is a self-hosted PaaS. ServerCompass is a deployment workflow tool. Which fits your needs? **Quick answer:** These tools solve different problems. **Coolify** is a self-hosted platform you run on your VPS. **ServerCompass** is a deployment workflow tool that gives you Vercel-like deploys without the platform overhead. ## Comparison Table | Criteria | Coolify | ServerCompass | |----------|---------|---------------| | **Type** | Self-hosted PaaS | Deployment workflow tool | | **Runs on your VPS** | Yes (as a service) | Deploys to your VPS | | **Resource overhead** | ~500MB RAM | Minimal (CLI-based) | | **App templates** | 100+ one-click apps | Framework-focused | | **Git integration** | Built-in webhooks | GitHub Actions integration | | **Rollbacks** | Manual | One-click rollbacks | | **Multi-app management** | Dashboard-based | Workflow-based | | **Learning curve** | Medium | Low | ## Coolify Overview Coolify is a self-hosted Heroku alternative. You install it on your VPS and it becomes your deployment platform. ### Strengths - **Full PaaS experience.** Dashboard, [database management](https://servercompass.app/features/data-import), SSL, the works. - **One-click apps.** [Deploy Supabase](https://servercompass.app/stacks/supabase), Plausible, Ghost with one click. - **Database management.** Create and manage databases through the UI. ### Weaknesses - **Resource overhead.** Coolify itself needs resources to run. - **Another system to maintain.** You're now maintaining a platform, not just apps. - **Context switching.** Different workflow than your normal dev process. ## ServerCompass Overview ServerCompass gives you Vercel-like deployment workflows on your own VPS without running a full platform. ### Strengths - **Minimal overhead.** No platform running on your VPS. - **Familiar workflow.** Git push, deploy, done. - **One-click rollbacks.** Instantly revert to previous versions. - **Framework-optimized.** Built for Next.js, Node.js, and modern stacks. ### Weaknesses - **Focused scope.** Not a full PaaS with app templates. - **Less visual.** Workflow-based rather than dashboard-based. ## When to Pick Coolify Pick Coolify if: - You want a full self-hosted PaaS experience - You need one-click app deployments (databases, tools) - You prefer a dashboard over CLI workflows - You're comfortable maintaining another platform ## When to Pick ServerCompass Pick ServerCompass if: - You want Vercel-like deploys without Vercel pricing - You deploy the same apps repeatedly - You want minimal VPS overhead - You value rollbacks and [deployment history](https://servercompass.app/features/deployment-history) ## Verdict **ServerCompass wins for teams focused on deploying their own apps.** If you're deploying Next.js, Node.js, or similar apps and want a clean workflow with rollbacks, ServerCompass fits better. **Coolify wins if you want a full platform** with database management, one-click apps, and a visual dashboard. ## Where to go next **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) - [Self-Host Supabase](https://deploytovps.com/self-host/supabase) **Related comparisons:** - [Coolify vs Dokploy](/compare/coolify-vs-dokploy) **ServerCompass:** - [Try ServerCompass](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Dokploy vs ServerCompass: Self-Hosted Deploy Tools Compared Source: https://deployhandbook.com/blog/compare/dokploy-vs-servercompass Published: 2026-03-06 Head-to-head comparison for developers choosing between Dokploy and ServerCompass for VPS deployments. **Quick answer:** Pick ServerCompass if you deploy frequently and want repeatable, team-friendly workflows. Pick Dokploy if you want a lightweight deploy UI with minimal overhead. ## Comparison Table | Criteria | Dokploy | ServerCompass | |----------|---------|---------------| | **Philosophy** | Simple deploy UI | Repeatable deployment workflows | | **Setup complexity** | Very simple | Simple with more config options | | **Best for** | Solo developers, small projects | Teams, multi-app deployments | | **Git integration** | Basic webhooks | Full CI/CD-like workflows | | **Learning curve** | Easy | Easy to Medium | | **Multi-[app management](https://servercompass.app/features/deployment-history)** | Supported | First-class support | | **Verdict** | Best for simplicity | Best for repeatability | ## Dokploy Overview ### Strengths - Extremely lightweight and simple - Minimal resource usage on the server - Quick to install and configure - Good for deploying a few apps - Clean, focused interface ### Weaknesses - Less suited for complex workflows - Limited template and preset system - Smaller community and ecosystem - Fewer automation features - Basic compared to full PaaS solutions ### Best for - Solo developers with simple needs - Small projects that rarely change - Developers wanting minimal overhead - Quick deployments without complexity ## ServerCompass Overview ### Strengths - Built for repeatable deployments - Strong multi-app and team support - Consistent workflows across projects - Better automation and presets - Active development focused on DX ### Weaknesses - Slightly more setup than Dokploy - More features mean more to learn - Newer in the self-hosted space - Requires understanding deployment patterns ### Best for - Teams deploying frequently - Multi-app environments - Developers wanting Vercel-like workflows on VPS - Projects that need consistency and repeatability ## When to pick Dokploy Pick Dokploy if: - You have one or two apps to deploy - You want the simplest possible setup - You prefer minimal tools over feature-rich platforms - Your deployment needs rarely change - You are a solo developer without team requirements ## When to pick ServerCompass Pick ServerCompass if: - You deploy multiple apps regularly - You want repeatable, documented workflows - You work with a team and need consistency - You want Vercel-like DX on your own VPS - You value automation and presets ## Verdict ServerCompass wins for developers who deploy frequently and want predictable, repeatable workflows. The focus on developer experience and multi-app management makes it the better choice for growing projects and teams. Dokploy is the right choice if simplicity is your only requirement. For solo developers with a few static projects, Dokploy gets the job done without overhead. Both tools assume you are comfortable running a VPS. If you want the benefits of self-hosting with less friction, ServerCompass provides the stronger foundation. ## Where to go next **Tutorials:** - [Deploy Docker Compose to VPS](https://deploytovps.com/deploy/docker-compose) - [VPS Security Basics](https://deploytovps.com/guide/vps-security) **Related comparisons:** - [Coolify vs Dokploy](/compare/coolify-vs-dokploy) - [Coolify vs ServerCompass](/compare/coolify-vs-servercompass) **ServerCompass:** - [Get started with ServerCompass](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Fly.io vs Railway: Infrastructure Control vs Platform Simplicity Source: https://deployhandbook.com/blog/compare/fly-vs-railway Published: 2026-03-06 Head-to-head comparison for developers choosing between Fly.io and Railway for deploying applications. **Quick answer:** Pick Fly.io if you want multi-region deployment and are comfortable with more infrastructure control. Pick Railway if you want the simplest path to deploy backends with databases. ## Comparison Table | Criteria | Fly.io | Railway | |----------|--------|---------| | **Pricing model** | Resource-based (CPU, RAM, bandwidth) | Resource-based ($5 min + usage) | | **Multi-region** | Native, easy to configure | Single region default | | **Database** | Fly Postgres (managed LiteFS) | Native Postgres, Redis, MySQL | | **Ease of setup** | Medium (flyctl CLI) | Easy (git push, UI) | | **Best for** | Global apps, latency-sensitive | Backends, databases, simplicity | | **Container support** | Full Docker support | Full Docker support | | **Verdict** | Best for global, infra-aware teams | Best for fast iteration | ## Fly.io Overview ### Strengths - True multi-region deployment with minimal config - Run containers close to users globally - Excellent for latency-sensitive applications - LiteFS for distributed SQLite - More infrastructure control and visibility ### Weaknesses - Steeper learning curve than Railway - CLI-first workflow (less UI polish) - Managed Postgres requires more setup - Bandwidth pricing can surprise you - Less beginner-friendly documentation ### Best for - Apps needing global low-latency - Teams comfortable with infrastructure concepts - Real-time applications (games, collaboration) - Edge-deployed services ## Railway Overview ### Strengths - One of the simplest deployment experiences - Native database provisioning in seconds - Clean UI for environment management - Great for teams and collaboration - Predictable pricing for most workloads ### Weaknesses - Single region by default (latency tradeoff) - Less infrastructure control - Not designed for edge or multi-region - Smaller ecosystem than Fly - Limited customization for advanced use cases ### Best for - Backend APIs and services - Full-stack apps with databases - Teams prioritizing speed over global reach - Projects that need Postgres, Redis, or MySQL fast ## When to pick Fly.io Pick Fly.io if: - You need multi-region deployment - Latency matters for your users globally - You are building real-time or edge-first apps - You want more control over infrastructure - You are comfortable with CLI workflows ## When to pick Railway Pick Railway if: - You want the fastest path to deploy - Your users are mostly in one region - You need databases without infrastructure work - You prefer UI-driven workflows - You are building a backend prototype or MVP ## Verdict Fly.io wins for teams that need global reach and are willing to invest in learning the platform. The multi-region story is significantly better than Railway, and you get more control over how your apps run. Railway wins on simplicity. If you want to deploy a backend with Postgres in five minutes and your users are mostly in one region, Railway is the faster path. For long-term cost control on stable workloads, consider whether a VPS gives you the best of both: control and predictable pricing. ## Where to go next **Tutorials:** - [Deploy Docker Compose to VPS](https://deploytovps.com/deploy/docker-compose) - [Deploy Node.js to VPS](https://deploytovps.com/deploy/nodejs) **Related comparisons:** - [Railway vs Render](/compare/railway-vs-render) - [Render vs DigitalOcean](/compare/render-vs-digitalocean) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Hetzner vs DigitalOcean: VPS Value Showdown Source: https://deployhandbook.com/blog/compare/hetzner-vs-digitalocean Published: 2026-03-06 Head-to-head comparison of the two most popular VPS providers for developers. One wins on price, the other on ecosystem. **Quick answer:** If cost matters, **Hetzner** wins. If you need US data centers, managed services, or a larger ecosystem, **DigitalOcean** is the safer choice. ## Comparison Table | Criteria | Hetzner | DigitalOcean | |----------|---------|--------------| | **Starting price** | $4.50/mo (2 vCPU, 4 GB) | $6/mo (1 vCPU, 1 GB) | | **Best value tier** | $7.50/mo (4 vCPU, 8 GB) | $24/mo (2 vCPU, 4 GB) | | **Data centers** | EU (Germany, Finland), US (Ashburn) | US, EU, Asia, Australia | | **Bandwidth** | 20 TB included | 1-6 TB (varies by plan) | | **Managed databases** | No | Yes (PostgreSQL, MySQL, Redis) | | **Kubernetes** | No managed option | Yes (DOKS) | | **Block storage** | $0.052/GB | $0.10/GB | | **Support** | Email only (free tier) | Ticket + community | ## Hetzner Overview Hetzner is a German hosting company known for aggressive pricing and solid infrastructure. They've been around since 1997 and have a strong reputation in Europe. ### Strengths - **Price-to-performance ratio is unmatched.** A 4 vCPU, 8 GB RAM server costs $7.50/mo. The same specs on DigitalOcean cost $48/mo. - **Generous bandwidth.** 20 TB included on all plans. DigitalOcean charges for overages much sooner. - **Dedicated vCPU options.** For workloads that need consistent performance, Hetzner's dedicated CPU plans are significantly cheaper. - **ARM servers available.** Ampere ARM64 servers at even lower prices for compatible workloads. ### Weaknesses - **Limited US presence.** Only one US data center (Ashburn, Virginia). If you need US West or other regions, you're out of luck. - **No managed services.** No managed databases, no managed Kubernetes. You're on your own for the ops layer. - **Support is basic.** Email only on free tier. No live chat, no phone support. - **Smaller ecosystem.** Fewer one-click apps, fewer integrations, smaller community. ### Best for - Cost-conscious teams running their own infrastructure - European companies with EU data residency requirements - High-bandwidth applications (video, backups, CDN origins) - Developers comfortable with self-managed infrastructure ## DigitalOcean Overview DigitalOcean is a US-based cloud provider that popularized the "developer-friendly VPS" category. They've expanded into managed services and Kubernetes. ### Strengths - **Global presence.** Data centers in US (multiple), EU, Asia, and Australia. Better for global latency. - **Managed services.** Managed PostgreSQL, MySQL, Redis, and Kubernetes. Less ops burden. - **Larger ecosystem.** More one-click apps, Terraform provider, extensive documentation. - **Better for teams.** Team management, invoicing, and organization features are more mature. ### Weaknesses - **2-3x more expensive.** For raw compute, you're paying a significant premium over Hetzner. - **Bandwidth limits.** 1-6 TB depending on plan. Overages add up quickly for high-traffic apps. - **Block storage is expensive.** $0.10/GB vs Hetzner's $0.052/GB. - **Performance variability.** Shared CPU instances can have noisy neighbors. ### Best for - Teams that want managed databases and Kubernetes - Companies with global users who need multiple regions - Startups that prioritize ecosystem and ease over cost - Projects with moderate bandwidth needs ## When to Pick Hetzner Pick Hetzner if: - **Cost is a primary concern.** The savings are substantial: 50-70% less for equivalent specs. - **You're comfortable with ops.** No managed databases means you're running PostgreSQL yourself. - **Your users are in Europe.** Hetzner's EU data centers have excellent connectivity. - **You have high bandwidth needs.** 20 TB included is hard to beat. - **You want dedicated CPU.** Hetzner's dedicated options are much cheaper. ## When to Pick DigitalOcean Pick DigitalOcean if: - **You need managed services.** Managed databases and Kubernetes reduce ops burden significantly. - **You have global users.** More regions mean better latency worldwide. - **You're a larger team.** Better team management and enterprise features. - **You value ecosystem.** More integrations, one-click apps, and community resources. - **You need US West or Asia.** Hetzner doesn't have these regions. ## Real Cost Comparison ### Small startup (2 servers, database, 5 TB bandwidth) | Provider | Monthly Cost | |----------|--------------| | **Hetzner** | ~$25/mo (self-managed DB) | | **DigitalOcean** | ~$80/mo (managed DB) | ### Growing SaaS (4 servers, managed DB, 10 TB bandwidth) | Provider | Monthly Cost | |----------|--------------| | **Hetzner** | ~$60/mo (self-managed) | | **DigitalOcean** | ~$200/mo (managed) | The gap widens as you scale. Hetzner's savings compound. ## Verdict **Hetzner wins for most developer use cases.** If you're a solo developer or small team that can manage your own infrastructure, Hetzner's value is hard to ignore. The 50-70% cost savings add up to thousands of dollars per year. **DigitalOcean wins if you need:** - Managed databases (don't want to run Postgres yourself) - Multiple global regions - Kubernetes without the setup overhead - A larger ecosystem and community For most projects starting out, I'd recommend **Hetzner + self-managed PostgreSQL**. When you grow and ops becomes a bottleneck, consider DigitalOcean's managed services or hire an ops person. ## Where to go next **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) - [Self-Host Supabase](https://deploytovps.com/self-host/supabase) **Related comparisons:** - [Render vs DigitalOcean](/compare/render-vs-digitalocean) **ServerCompass:** - [Deploy to any VPS with one click](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Railway vs Render: PaaS for Developers Compared Source: https://deployhandbook.com/blog/compare/railway-vs-render Published: 2026-03-06 Both promise easy deployments for developers. Which one delivers better value? **Quick answer:** **Railway** wins for developer experience and startup speed. **Render** wins for feature breadth and free tier. ## Comparison Table | Criteria | Railway | Render | |----------|---------|--------| | **Starting price** | $5/mo (usage-based) | $0 (free tier) | | **Free tier** | $5 credit/mo | 750 hours/mo (sleeps) | | **Deploy speed** | Very fast | Fast | | **Database** | Built-in PostgreSQL, Redis | Managed PostgreSQL, Redis | | **Cron jobs** | Yes | Yes | | **Private networking** | Yes | Yes | | **Docker support** | Yes | Yes | | **Monorepo support** | Excellent | Good | | **DX focus** | Primary | Secondary | ## Railway Overview Railway is a newer PaaS focused heavily on developer experience. It's known for its clean UI and fast deployments. ### Strengths - **Exceptional DX.** The dashboard is clean, fast, and intuitive. - **Fast deployments.** Consistently quick build and deploy times. - **Great monorepo support.** Handles complex project structures well. - **Usage-based pricing.** Pay for what you use, not fixed tiers. - **Instant databases.** Spin up PostgreSQL or Redis in seconds. ### Weaknesses - **No true free tier.** $5 credit runs out quickly with always-on services. - **Smaller feature set.** Fewer managed services than Render. - **Newer platform.** Less battle-tested than some alternatives. ### Best for - Developers who value clean tooling - Startups moving fast - Projects with monorepo structures - Backend-heavy applications ## Render Overview Render is a more established PaaS with a broader feature set and a genuine free tier. ### Strengths - **Real free tier.** 750 hours of free compute (services sleep after inactivity). - **Broader services.** Static sites, cron jobs, managed databases, Redis. - **More regions.** Better global coverage than Railway. - **Blueprints.** Infrastructure-as-code for reproducible deployments. ### Weaknesses - **Free tier sleeps.** Services spin down after 15 minutes of inactivity. - **DX not as polished.** Functional but not as refined as Railway. - **Slower cold starts.** Sleeping services take time to wake up. ### Best for - Side projects that can tolerate sleeping - Teams needing broader service options - Projects requiring infrastructure-as-code ## Pricing Comparison ### Hobby project (1 service, small database) | Provider | Monthly Cost | |----------|--------------| | **Railway** | $5-15/mo | | **Render** | $0 (free tier) or $7/mo | ### Small SaaS (2 services, database, Redis) | Provider | Monthly Cost | |----------|--------------| | **Railway** | $20-40/mo | | **Render** | $25-50/mo | ### Growing startup (5+ services, larger databases) | Provider | Monthly Cost | |----------|--------------| | **Railway** | $100-200/mo | | **Render** | $100-250/mo | ## When to Pick Railway Pick Railway if: - Developer experience is a priority - You're deploying backend services frequently - You have a monorepo structure - You want usage-based pricing ## When to Pick Render Pick Render if: - You want a true free tier for side projects - You need infrastructure-as-code (Blueprints) - You want more global regions - You need static site hosting alongside backends ## Verdict **Railway wins for developer experience.** If you're a developer who values clean, fast tooling, Railway is the better choice. The DX is noticeably better. **Render wins for budget-conscious projects** that can use the free tier, or teams that need infrastructure-as-code. For production workloads where cost matters, consider a VPS instead. Both Railway and Render cost 3-5x more than equivalent VPS resources. ## Where to go next **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) - [Deploy Node.js to VPS](https://deploytovps.com/deploy/nodejs) **Related comparisons:** - [Railway Alternatives](/alternatives/railway) - [Vercel vs Railway](/compare/vercel-vs-railway) **ServerCompass:** - [VPS deploys with PaaS convenience](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Render vs DigitalOcean: Managed PaaS vs Flexible Cloud Source: https://deployhandbook.com/blog/compare/render-vs-digitalocean Published: 2026-03-06 Head-to-head comparison for developers choosing between Render and DigitalOcean for hosting applications. **Quick answer:** Pick Render if you want managed deploys without infrastructure work. Pick DigitalOcean if you want flexibility, App Platform simplicity, or raw VPS control. ## Comparison Table | Criteria | Render | DigitalOcean | |----------|--------|--------------| | **Pricing** | $7/mo starter, usage-based | $5/mo Droplet, $5/mo App Platform | | **Ease of setup** | Very easy (git push) | Easy (App Platform) to Medium (Droplet) | | **Database** | Managed Postgres | Managed Postgres, MySQL, Redis | | **Flexibility** | Limited to platform | Full control with Droplets | | **Scaling** | Automatic | Manual (Droplet) or Auto (App Platform) | | **Best for** | Quick deploys, small teams | Growing teams, mixed workloads | | **Verdict** | Best for simplicity | Best for flexibility | ## Render Overview ### Strengths - One of the easiest deployment platforms - Native Postgres and Redis provisioning - Automatic SSL and custom domains - [Preview environments](https://servercompass.app/docs/preview-environments) on PRs - Background workers and cron jobs built-in ### Weaknesses - Less flexible than IaaS options - Pricing increases quickly with scale - Limited regions compared to DigitalOcean - Less control over infrastructure - Cold starts on free tier ### Best for - Small teams wanting managed deployments - Projects that need workers and databases together - Teams avoiding infrastructure complexity - Quick prototypes and MVPs ## DigitalOcean Overview ### Strengths - Flexible: App Platform (PaaS) or Droplets (VPS) - Predictable Droplet pricing at scale - Extensive managed database options - Global datacenter coverage - Strong documentation and community ### Weaknesses - App Platform less polished than Render - Droplets require more setup and ops work - No built-in preview environments - Less streamlined git-push workflow - More decisions to make upfront ### Best for - Teams wanting PaaS simplicity with VPS escape hatch - Long-term cost-conscious projects - Mixed workloads (apps, databases, storage) - Teams comfortable with some infrastructure ## When to pick Render Pick Render if: - You want the absolute simplest deployment path - Preview environments matter for your workflow - You need workers, cron, and databases in one place - Your team is small and wants to avoid ops entirely - You are building a prototype or early-stage product ## When to pick DigitalOcean Pick DigitalOcean if: - You want flexibility between PaaS and VPS - Cost predictability matters at scale - You might outgrow PaaS and want an easy migration - You need more datacenter region options - You are comfortable with basic infrastructure decisions ## Verdict DigitalOcean is the more versatile choice for most teams. Start with App Platform for simplicity, and migrate to Droplets when you need more control or cost efficiency. This flexibility is valuable as projects grow. Render wins on pure simplicity. If you want the fastest path to deploy and your project will stay small, Render delivers a great experience with less friction. For long-term cost control, DigitalOcean Droplets or a Hetzner VPS will outperform both platforms on price-to-performance. ## Where to go next **Tutorials:** - [Deploy Docker to DigitalOcean](https://deploytovps.com/deploy/docker-compose) - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) **Related comparisons:** - [Hetzner vs DigitalOcean](/compare/hetzner-vs-digitalocean) - [Railway vs Render](/compare/railway-vs-render) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Vercel vs Netlify: The JAMstack Platform Showdown Source: https://deployhandbook.com/blog/compare/vercel-vs-netlify Published: 2026-03-06 Head-to-head comparison for developers choosing between Vercel and Netlify for frontend hosting. **Quick answer:** Vercel is the better choice for most modern frontend apps, especially Next.js. Netlify remains strong for static sites with built-in forms and identity. ## Comparison Table | Criteria | Vercel | Netlify | |----------|--------|---------| | **Pricing** | $20/mo Pro + usage | $19/mo Pro + usage | | **Best framework** | Next.js (owns it) | Framework-agnostic | | **Edge functions** | Mature, global | Available, less mature | | **Build minutes** | 6000/mo Pro | 1000/mo Pro | | **Forms** | External only | Built-in | | **Identity/Auth** | External only | Built-in | | **Verdict** | Best for dynamic apps | Best for static + forms | ## Vercel Overview ### Strengths - First-party Next.js support (Vercel owns Next.js) - Superior edge function performance - Automatic ISR and caching optimization - More generous build minute allowance - Better monorepo and workspace support ### Weaknesses - No built-in form handling - No native authentication service - Usage-based pricing can spike - Less suitable for purely static sites - Bandwidth costs accumulate faster ### Best for - Next.js applications (the obvious choice) - React-based apps with SSR or ISR - Teams prioritizing performance over features - Apps needing edge middleware ## Netlify Overview ### Strengths - Built-in form handling without backends - Native identity and authentication - Plugin ecosystem for extending builds - Good for static sites with simple needs - Split testing built-in ### Weaknesses - Slower edge function adoption - Less optimized for Next.js specifically - Lower build minute allowance on Pro - Falls behind on SSR/ISR features - Identity service has limitations at scale ### Best for - Static marketing sites - Sites needing contact forms without backends - Projects using Gatsby, Hugo, or Eleventy - Teams wanting auth without external services ## When to pick Vercel Pick Vercel if: - You are using Next.js (no contest) - Edge performance is critical - You need ISR or complex caching strategies - Build times are long and you need more minutes - You want the most polished deployment experience ## When to pick Netlify Pick Netlify if: - You need built-in form handling - Your site is mostly static with simple dynamic needs - You want identity/auth without integrating external services - You are using Gatsby, Hugo, or other static generators - Split testing is part of your workflow ## Verdict Vercel is the stronger platform for modern frontend development in 2026. If you are building with Next.js, the choice is obvious. Vercel has better edge support, more build minutes, and tighter framework integration. Netlify still wins for teams building static sites that need forms and basic auth without external dependencies. For everything else, Vercel delivers a better developer experience. If cost is your primary concern, both platforms get expensive at scale. Consider a VPS-based approach for predictable billing. ## Where to go next **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) - [Deploy Astro to VPS](https://deploytovps.com/deploy/astro) **Related comparisons:** - [Vercel vs Railway](/compare/vercel-vs-railway) - [Vercel Alternatives](/alternatives/vercel) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Vercel vs Railway: Frontend Platform vs Backend-First PaaS Source: https://deployhandbook.com/blog/compare/vercel-vs-railway Published: 2026-03-06 Head-to-head comparison for developers choosing between Vercel and Railway for their next project. **Quick answer:** Pick Vercel if your app is frontend-heavy with serverless functions. Pick Railway if you need databases, workers, and backend services in one place. ## Comparison Table | Criteria | Vercel | Railway | |----------|--------|---------| | **Pricing model** | Usage-based (bandwidth, functions, builds) | Resource-based ($5 min + usage) | | **Best for** | Next.js, frontend, edge functions | Full-stack apps, backends, databases | | **Database support** | External only (Supabase, Planetscale) | Native Postgres, Redis, MySQL | | **Ease of setup** | Easy (git push) | Easy (git push) | | **Scalability** | Auto-scales, global edge | Auto-scales, single region default | | **Build minutes** | 6000/mo on Pro | Unlimited on paid plans | | **Verdict** | Best for JAMstack and edge | Best for backend-first apps | ## Vercel Overview ### Strengths - Unmatched Next.js integration and optimization - Global edge network with automatic routing - Zero-config deployments for most frontend frameworks - Preview deployments on every PR - Strong caching and ISR support ### Weaknesses - Usage pricing becomes unpredictable at scale - No native database or persistent services - Serverless functions have cold start latency - Backend-heavy apps require external services - Bandwidth costs add up quickly ### Best for - Next.js applications - Static sites with dynamic edges - Teams prioritizing DX over cost control - Marketing sites and landing pages ## Railway Overview ### Strengths - Deploy any Docker container or language - Native Postgres, Redis, and MySQL databases - Predictable resource-based pricing - Great for monorepos and multi-service apps - Simple environment variable management ### Weaknesses - No edge network (single region by default) - Less optimized for pure frontend workloads - Smaller ecosystem of templates - No built-in image optimization - Less mature than Vercel for static assets ### Best for - Full-stack applications with databases - Backend APIs and workers - Teams wanting all services in one platform - Projects that outgrow serverless limits ## When to pick Vercel Pick Vercel if: - You are building a Next.js or frontend-first app - Edge performance and global CDN matter most - You want the fastest path from code to production - Your backend is already handled elsewhere (Supabase, external APIs) - Preview deployments are critical to your workflow ## When to pick Railway Pick Railway if: - You need databases and backend services together - You want predictable pricing without usage surprises - Your app has workers, cron jobs, or background tasks - You prefer resource-based billing over function invocations - You are building a traditional backend or API-first product ## Verdict Neither platform is universally better. Vercel is the clear winner for frontend-heavy, edge-first applications, especially Next.js. Railway wins when you need a complete backend stack with databases and workers in one place. For teams building full-stack apps that need both: consider Railway for your backend services and a VPS for long-term cost control, or evaluate whether a self-hosted stack gives you more flexibility. ## Where to go next **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) - [Deploy Node.js API to VPS](https://deploytovps.com/deploy/nodejs) **Related comparisons:** - [Railway vs Render](/compare/railway-vs-render) - [Vercel vs Netlify](/compare/vercel-vs-netlify) **ServerCompass:** - [One-click deploys on your VPS](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- ## Fly.io Pricing Explained (2026): Shared CPU, Bandwidth, and Real App Costs Source: https://deployhandbook.com/blog/pricing/fly-io Published: 2026-03-06 A practical Fly.io pricing walkthrough focused on what you actually pay for: shared CPU instances, bandwidth, storage, and the costs that surprise teams. Fly.io is one of the best options when you want more control than a PaaS but do not want the full DIY burden of a raw VPS. It is also easy to misunderstand because the pricing is not "one plan". It is a set of resources. This guide is meant to make Fly pricing predictable enough that you can decide quickly. ## What you pay for on Fly.io At a high level, you pay for: - compute (CPU/RAM via machine size) - storage (volumes) - bandwidth (especially egress) - optional services (depending on your stack) If your mental model is "my app costs $X/month", convert your app into those resources. That is the only way to avoid surprises. ## Shared CPU pricing (what most apps start with) Shared CPU machines are the default choice for small and medium apps. They are cost-effective, but you must accept that you share the physical CPU. Shared CPU is a good fit when: - your workload is mostly IO bound (API calls, DB queries) - you do not run sustained CPU-heavy jobs - you care about cost more than peak performance If you run sustained compute (video, ML, heavy transforms), move to dedicated CPU. ## Real app costs (three practical examples) ### Example 1: a small API with one region - 1 small machine - minimal bandwidth - small database elsewhere Cost signal: **low double digits** for many teams. ### Example 2: Next.js app + API + a worker - web machine - api machine - worker machine (jobs) - some storage Cost signal: **$20 to $50/month**, depending on your machine sizes and traffic. ### Example 3: global traffic with 2-3 regions Multi-region is where Fly shines, and where cost can grow if you do not plan: - more machines - more network traffic - more operational complexity Cost signal: still often cheaper than a "usage-heavy" PaaS, but not free. ## Hidden cost #1: Bandwidth and egress patterns Bandwidth is the classic surprise. You get in trouble when: - you serve images/media from the app - you return large JSON payloads at scale - you proxy third-party assets Fixes: - put media behind a CDN (Cloudflare R2, S3, etc.) - compress responses - cache at the edge when it makes sense ## Hidden cost #2: Storage volumes Volumes are not complicated, but they are easy to forget. If you run anything stateful on Fly, you pay for: - disk - snapshots/backups (depending on your setup) Many teams keep state in managed services, and use Fly for compute only. That keeps pricing easier. ## When Fly beats a VPS (and when it does not) Fly beats a VPS when: - you want a middle ground: control without full DIY - you want multi-region routing without building it yourself - you are okay with a bit of infrastructure learning VPS beats Fly when: - you want the lowest possible flat cost - your workload is stable and single-region - you are happy running [Docker Compose](https://servercompass.app/features/docker-compose-editor) + a reverse proxy If you are deciding between Fly and a flat-cost VPS provider, read: https://servercompass.app/compare/flyio?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta ## Where to go next (internal links) - Tutorials: - `/deploy/docker` - `/guide/traefik-ssl` - Comparison: - `/compare/hetzner-vs-digitalocean` - ServerCompass: - https://servercompass.app/compare/flyio?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. If you regularly stitch together PDF, image, video, or batch-file workflows like the ones above, [1FileTool](https://1filetool.com) is the StoicSoft network's purpose-built desktop app — 245+ local-first tools, pay-once, files never leave the device. --- ## Hetzner Pricing Breakdown (2026): Best Value VPS for Developers Source: https://deployhandbook.com/blog/pricing/hetzner Published: 2026-03-06 Hetzner Cloud pricing explained. Why European VPS pricing beats US providers, and what you actually pay for production workloads. Hetzner is the open secret of cost-conscious developers. European pricing, generous bandwidth, and specs that embarrass US providers at the same price point. This is what Hetzner actually costs for real workloads. ## Pricing Tiers Overview | Instance | vCPU | RAM | Storage | Price | |----------|------|-----|---------|-------| | CX22 | 2 | 4 GB | 40 GB | $4.35/mo | | CX32 | 4 | 8 GB | 80 GB | $7.59/mo | | CX42 | 8 | 16 GB | 160 GB | $14.49/mo | | CX52 | 16 | 32 GB | 240 GB | $28.99/mo | Dedicated CPU options exist for CPU-bound workloads at higher prices. All instances include 20TB outbound traffic. That is not a typo. ## Real-World Cost Examples ### Example 1: Side project (single app) - CX22 (2 vCPU, 4GB RAM) - Docker + Traefik - PostgreSQL in container - 1-2 apps **Actual cost: $4.35/mo** This handles more than most $20-50/mo PaaS setups. Seriously. ### Example 2: Small SaaS (multiple services) - CX32 (4 vCPU, 8GB RAM) - 3-5 Docker services - PostgreSQL + Redis - Background workers - Staging on same server or second CX22 **Actual cost: $7.59-12/mo** One server runs your entire stack. Add a second for staging if needed. ### Example 3: Growing startup (production-grade) - CX42 (8 vCPU, 16GB RAM) for production - CX22 for staging - Managed backups - Load balancer (optional) - Block storage for data **Actual cost: $20-35/mo** This is "serious production" territory. Most startups never need more. ## Hidden Costs to Watch ### 1. There are almost none This is the point. Hetzner pricing is what it says. No bandwidth surprises, no per-request fees, no seat charges. ### 2. Backups are extra (but cheap) Automated backups cost 20% of server price. A CX32 backup is ~$1.50/mo. Worth it. ### 3. Load balancers if you need them $6.41/mo for a load balancer. Most small apps do not need one. ### 4. Block storage for large data $0.052/GB/month. Only relevant if you store large files or databases that outgrow instance storage. ### 5. Your time is a cost Unlike managed PaaS, you handle setup and maintenance. Tools like Coolify, Dokploy, or ServerCompass reduce this significantly. ## Cost Comparison | Platform | Starter | Production | Bandwidth | |----------|---------|------------|-----------| | Hetzner | $4.35 | $12-25 | 20TB included | | DigitalOcean | $6 | $24-48 | 2-4TB included | | Linode | $5 | $20-40 | 2-4TB included | | Vultr | $6 | $24-48 | 2-3TB included | | AWS Lightsail | $5 | $40-80 | 2-5TB included | Hetzner wins on raw value. The 20TB bandwidth alone saves money for traffic-heavy apps. ## When Hetzner Makes Sense Use Hetzner when: - You want the best specs per dollar - You can handle basic server administration (or use a deployment tool) - Your traffic is predictable or growing - You want to escape per-seat or per-service pricing Consider alternatives when: - You need US-based servers (Hetzner has US datacenter in Ashburn, VA) - You want zero ops responsibility - You need managed databases with automatic failover - Compliance requires specific cloud certifications ## The Setup Trade-off Hetzner gives you a blank server. You add: - Docker and [Docker Compose](https://servercompass.app/features/docker-compose-editor) - Reverse proxy (Traefik, Nginx, Caddy) - [SSL certificates](https://servercompass.app/docs/ssl-certificates) (automated via Let's Encrypt) - Monitoring and backups This takes 1-2 hours manually, or minutes with deployment tools. **Tools that automate this:** - Coolify (open source PaaS) - Dokploy (open source PaaS) - ServerCompass (deployment automation) - CapRover (open source PaaS) ## My Recommendation Hetzner is the correct choice for most indie developers and small teams who want control and low cost. The CX22 at $4.35/mo handles what costs $50+/mo on managed platforms. The CX32 at $7.59/mo is production-ready for most SaaS apps. If you have shipped on Vercel/Railway/Render and want to cut costs 80%, Hetzner is the answer. ## Where to go next **Comparisons:** - [Hetzner vs DigitalOcean](/compare/hetzner-vs-digitalocean) **Tutorials:** - [Deploy to VPS with Docker](https://deploytovps.com/deploy/docker) - [Self-host your stack](https://deploytovps.com/self-host/supabase) **ServerCompass:** - [One-click deploys on Hetzner](https://servercompass.app?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Railway Pricing 2026: Why Your $5 App Will Cost $40+ in Production Source: https://deployhandbook.com/blog/pricing/railway Published: 2026-03-06 A realistic way to estimate Railway cost in production, what drives the bill, and when a VPS becomes the better deal. Railway is one of the best "deploy fast" platforms for small teams. It is also one of the easiest to underestimate. This page is a pricing teardown, not a marketing summary. The goal is to help you answer one question: **What will Railway cost for a real app in production?** ## The simple model: Railway costs are "baseline + growth taxes" For most apps, the Railway bill is driven by: - the number of services you run (API, worker, cron, etc.) - CPU/RAM sizing for each service - database resources - bandwidth and egress patterns - uptime expectations (how many environments you keep always-on) If you keep the architecture minimal, the bill stays reasonable. If you accidentally build "microservices by default", Railway gets expensive fast. ## Comparison table (quick context) | Platform | Typical cost range | |---|---| | Railway | $15-$60 | | Vercel | $20-$80 | | Fly.io | $10-$50 | | Hetzner VPS | $6-$10 | This is not "official pricing". It is what teams usually experience when they run a real project with a database and background jobs. ## Realistic Railway scenarios ### Scenario A: single backend + Postgres (starter production) This is the "one API service" setup: - 1 Node API service - 1 Postgres database - 1 environment What happens: - the app runs smoothly - the bill stays near the low end Typical cost signal: **~$15 to $30/month** ### Scenario B: backend + worker + cron + Postgres (most teams by month 2) This is where cost jumps: - API service - worker service (queues) - cron service - Postgres - staging environment you forgot to sleep Typical cost signal: **~$30 to $60/month** The main driver is not that Railway is "bad". It is that you now have multiple always-on services. ### Scenario C: spiky traffic + logs + heavy egress (surprise month) The predictable surprise is bandwidth and operational extras (logs, metrics, etc.). If you ship large responses or serve media, your bill becomes harder to reason about. Typical cost signal: **$60+/month**, depending on how much "platform convenience" you keep enabled. ## Where teams get surprised ### 1. Keeping staging always-on If your staging environment is always running, it is production cost in disguise. Fix: - sleep it automatically - keep it only when you actively test ### 2. Adding "just one more service" One more service usually means: - one more bill line item - one more place to debug If you can keep background jobs inside the same service for a while (even if it is not perfect), you buy time. ### 3. The database becomes the expensive part Databases are not expensive because vendors are evil. They are expensive because production databases need: - storage - memory - backup/replication - reliability guarantees If you are paying for that, at some point a VPS becomes attractive. ## When a VPS is cheaper (and when it is not) ### VPS is cheaper when - you run **multiple services** - you want a flat monthly cost - you can accept basic ops responsibilities (backup, upgrades) The baseline VPS path most teams take: - one $6 to $12 VPS - [Docker Compose](https://servercompass.app/features/docker-compose-editor) - Traefik or Nginx reverse proxy - daily backups ### VPS is not cheaper when - you do not want to be on call for infrastructure - you need managed reliability and do not have ops skills - your app is early and you value speed more than cost ## My recommendation (pragmatic) - Use Railway to ship and learn quickly. - Once you have stable traffic and more than 2-3 always-on services, treat a VPS migration as an engineering investment that pays off monthly. If you want to keep the "push to deploy" workflow while moving to a VPS, compare here: https://servercompass.app/compare/railway?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta ## Where to go next (internal links) - Tutorials: - `/deploy/nodejs` - `/deploy/docker-compose` - Comparison: - `/compare/railway-vs-render` - ServerCompass: - https://servercompass.app/compare/railway?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta --- **Related in the StoicSoft network** If you're self-hosting on a VPS or working through a deployment guide like the one above, [DeployToVPS](https://deploytovps.com) is the StoicSoft network's handbook for VPS deployment recipes — docker-compose, nginx, traefik, and common app self-hosts. --- ## Render Pricing Breakdown (2026): What You Actually Pay Source: https://deployhandbook.com/blog/pricing/render Published: 2026-03-06 Render pricing explained with real cost examples. Per-service billing, bandwidth, and database costs that most teams underestimate. Render positions itself as the simpler alternative to Heroku. The pricing reflects that: straightforward per-service billing instead of usage-based surprises. But "simple" does not mean "cheap". Here is what Render actually costs. ## Pricing Tiers Overview | Service Type | Free | Starter | Standard | |--------------|------|---------|----------| | Web Service | $0 (suspends) | $7/mo | $25/mo | | Private Service | - | $7/mo | $25/mo | | Background Worker | - | $7/mo | $25/mo | | Cron Job | - | $1/mo | $1/mo | | PostgreSQL | $0 (90 days) | $7/mo | $20/mo | | Redis | - | $10/mo | $25/mo | The catch: free tier services suspend after 15 minutes of inactivity. Not useful for production. ## Real-World Cost Examples ### Example 1: Side project (simple web app) - 1 web service (Starter) - Free PostgreSQL (90-day limit) - Minimal traffic **Actual cost: $7/mo** (then $14/mo after free DB expires) Good for learning and prototypes. The free database has a hard expiration. ### Example 2: Small SaaS (API + database + worker) - 1 web service (Standard): $25 - 1 background worker (Starter): $7 - 1 PostgreSQL (Starter): $7 - 1 Redis (Starter): $10 **Actual cost: $49/mo** This is the "real app" baseline. Most production apps land here or higher. ### Example 3: Growing startup (multiple services, staging) - 2 web services (Standard): $50 - 2 background workers (Standard): $50 - 1 PostgreSQL (Standard): $20 - 1 Redis (Standard): $25 - Staging environment (duplicate): ~$75 **Actual cost: $150-220/mo** Staging environments double your cost. Teams often forget this. ## Hidden Costs to Watch ### 1. Per-service billing adds up Unlike usage-based platforms, every service is a line item. A "microservices" architecture becomes expensive fast. Consolidate where you can. ### 2. Database pricing scales steeply The $7 starter PostgreSQL has 1GB storage and limited connections. Production apps often need Standard ($20) or higher. Large databases cost $85-185/mo. ### 3. Bandwidth is not unlimited Render includes bandwidth, but egress-heavy apps (media, large APIs) can hit limits. Check your usage patterns. ### 4. Free tier suspensions kill UX Free services suspend after inactivity. Your first visitor waits 30+ seconds for cold start. Not viable for anything user-facing. ### 5. Staging is a full duplicate cost No "preview environment" magic. Staging means paying for every service twice. ## Cost Comparison | Platform | Starter | Production | Model | |----------|---------|------------|-------| | Render | $19 | $50-150 | Per-service | | Railway | $15 | $60+ | Usage-based | | Vercel | $20/seat | $80+ | Per-seat + usage | | Fly.io | $5 | $25-50 | Resource-based | | Hetzner VPS | $6 | $12-25 | Flat monthly | ## When Render Makes Sense Use Render when: - You want predictable, per-service billing - You prefer a simpler model than usage-based pricing - You need managed PostgreSQL without running your own - Your architecture has 2-4 services max Consider switching when: - You run 5+ services and costs stack - You need staging without doubling the bill - Your database needs outgrow the managed tiers - A flat VPS cost looks better than per-service math ## The VPS Alternative A single [VPS with Docker](https://servercompass.app/blog/deploy-laravel-on-vps-with-docker) Compose runs unlimited services for one flat fee: - Hetzner CX22: $6/mo (2 vCPU, 4GB RAM) - Hetzner CX32: $12/mo (4 vCPU, 8GB RAM) You run your own PostgreSQL, Redis, workers, and cron. One bill. The tradeoff is setup and maintenance. Tools like Coolify or ServerCompass automate most of it. ## My Recommendation Render is a good middle ground: simpler than Heroku was, more managed than a VPS. But once you have more than 3-4 services, the math changes. A $12 VPS can host what costs $100+/mo on Render. Use Render to ship quickly. Migrate when service count makes VPS math obvious. ## Where to go next **Comparisons:** - [Railway vs Render](/compare/railway-vs-render) **Tutorials:** - [Deploy to VPS with Docker Compose](https://deploytovps.com/deploy/docker-compose) **ServerCompass:** - [Compare Render to VPS hosting](https://servercompass.app/compare/render?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Vercel Pricing Breakdown (2026): Real Costs Explained Source: https://deployhandbook.com/blog/pricing/vercel Published: 2026-03-06 What Vercel actually costs in production. Build minutes, bandwidth, and serverless invocations add up faster than the pricing page suggests. Vercel pricing looks simple on the surface: Hobby is free, Pro is $20/month per seat. But once you have real traffic, the bill tells a different story. This is a breakdown of what Vercel actually costs, not the marketing version. ## Pricing Tiers Overview | Tier | Base Price | What You Get | |------|------------|--------------| | Hobby | $0 | 1 user, 100GB bandwidth, 100 build hours | | Pro | $20/seat/mo | Team features, 1TB bandwidth, 400 build hours | | Enterprise | Custom | SLAs, advanced security, dedicated support | The base price is not the problem. The overages are. ## Real-World Cost Examples ### Example 1: Side project (personal blog, portfolio) - Traffic: 5,000 visitors/month - Build minutes: 10/month - Serverless invocations: minimal **Actual cost: $0/mo** The Hobby tier covers this easily. No surprises. ### Example 2: Small SaaS (early product, 1-3 team members) - Traffic: 50,000 visitors/month - Build minutes: 50/month - Serverless invocations: 500k/month - 2 team members on Pro **Actual cost: $40-60/mo** The $40 base (2 seats) plus potential overage on serverless functions. This is where you start watching the dashboard. ### Example 3: Growing startup (real traffic, active development) - Traffic: 500,000 visitors/month - Build minutes: 200/month - Serverless invocations: 5M/month - 5 team members on Pro - Edge functions, image optimization **Actual cost: $150-300/mo** Per-seat pricing stacks. Bandwidth and function invocations add variable cost. Image optimization and edge compute are separate line items. ## Hidden Costs to Watch ### 1. Per-seat pricing compounds fast $20/seat sounds fine until you have 8 developers. That is $160/month before any usage. ### 2. Serverless function invocations The free tier includes 100k invocations on Hobby, 1M on Pro. After that, you pay per million. API-heavy apps hit this limit faster than expected. ### 3. Bandwidth overages Pro includes 1TB. Sounds like a lot until you serve images, PDFs, or large API responses. Overage is $40/100GB. ### 4. Build minutes during active development If your team pushes frequently and your builds take 5+ minutes, 400 hours goes faster than you think. Overage is $10/100 hours. ### 5. Image optimization Vercel's image optimization is convenient but priced separately. High-traffic sites with many images can see this line item grow. ## Cost Comparison | Platform | Starter | Production | Model | |----------|---------|------------|-------| | Vercel | $20/seat | $80-300+ | Per-seat + usage | | Railway | $15 | $60+ | Usage-based | | Fly.io | $5 | $25-50 | Resource-based | | Render | $19 | $50-100 | Per-service | | Hetzner VPS | $6 | $12-25 | Flat monthly | ## When Vercel Makes Sense Use Vercel when: - You prioritize developer experience over cost optimization - Your team deploys Next.js apps and wants zero-config - You need edge functions and global CDN without setup - Your traffic is predictable or you have budget flexibility Consider switching when: - Per-seat pricing exceeds your infrastructure budget - You have stable traffic and can accept some ops work - You run multiple apps and want consolidated billing - Serverless invocation costs become unpredictable ## The VPS Alternative A single Hetzner VPS ($6-12/mo) can host multiple apps with: - Flat, predictable cost - No per-seat charges - No invocation limits - Full control over your stack The tradeoff is setup time and ops responsibility. Tools like ServerCompass bridge this gap. ## My Recommendation Vercel is excellent for shipping fast. The DX is unmatched for Next.js. But if your bill is climbing and your traffic is stable, a VPS migration pays for itself within 2-3 months for most teams. Start on Vercel. Graduate when the math stops working. ## Where to go next **Alternatives:** - [Vercel Alternatives](/alternatives/vercel) **Tutorials:** - [Deploy Next.js to VPS](https://deploytovps.com/deploy/nextjs) **ServerCompass:** - [Compare Vercel to VPS hosting](https://servercompass.app/compare/vercel?utm_source=deployhandbook&utm_medium=referral&utm_campaign=cta) --- **Related in the StoicSoft network** If you're choosing a VPS provider or benchmarking real-world performance like the post above explores, [StoicVPS](https://stoicvps.com) is the StoicSoft network's independent tracker for VPS pricing, performance, and migration safety. --- ## Self-hosters need a middle path between one Compose VM and full platform engineering Source: https://deployhandbook.com/blog/compare/docker-compose-vm-vs-full-platform-engineering Tags: docker-compose, platform-engineering, vps, homelab, monitoring Most self-hosters eventually hit a wall: a single Docker Compose VM starts to creak, but building a full internal platform with Nomad, Consul, Vault, and custom automation is a project in itself. There is a practical middle path worth knowing. Most self-hosters eventually hit a wall: a single Docker Compose VM starts to creak, but building a full internal platform with Nomad, Consul, Vault, and custom automation is a project in itself. ## The two extremes On one end you have the battle-hardened single VM: Docker Compose, Traefik as a reverse proxy, Cloudflare for DNS and DDoS protection, maybe a nightly backup cronjob. It works well until it doesn't. One bad compose file or a runaway container takes everything down. There's no isolation between services, no easy way to roll back a broken deployment, and monitoring is often an afterthought — a few Uptime Kuma checks and a Telegram alert if the site stops responding. On the other end you have what some operators are building in their homelabs: a full virtual datacenter. One KVM homelab author documented building out DNS, PXE boot, NFS storage, service lifecycle management, snapshot workflows, and automated health checks — essentially the same infrastructure patterns a cloud provider runs, just at home. Another operator migrated their public-service workloads from a hardened Compose VM into a TrueNAS-backed Nomad and Consul cluster, with Vault for secrets, a WireGuard mesh, an internal PKI, custom Python automation for deployments, a status page for users, and documented recovery paths for every failure scenario. Both approaches are legitimate. The second one is impressive engineering. It's also weeks or months of work before you ship a single line of your actual application. ## Where operator fatigue sets in The problem with the full platform path is not the complexity itself — it's the maintenance surface. Every component you add is something that can break on a Sunday night. Consul has to be healthy for Nomad to schedule jobs. Vault needs to be unsealed. Your internal PKI needs renewals. Your Python automation has to handle edge cases you didn't think of when you wrote it. A mobile-first homelab NOC builder described exactly this problem: they're trying to unify asset health, SSL and domain expiry monitoring, private uptime checks, Docker container state, and recovery visibility into a single coherent view. That's not a feature request — it's operator fatigue expressing itself as a dashboard problem. When you're running public services (not just home automation), the maintenance overhead of a full platform directly competes with the time you have to work on the thing you actually wanted to host. ## What the middle path looks like The practical middle path is not a new tool category — it's a set of decisions that let you add structure incrementally without committing to a full platform upfront. **One VM per concern, not one service per VM.** Instead of cramming everything into one Compose file, group services by failure domain. Your public-facing web apps in one VM, your databases in another, your internal tooling in a third. This gives you isolation without the overhead of a scheduler. **Treat your Compose files as the deployment unit.** Version-control each one, use `.env` files for configuration, and deploy with a simple `git pull && docker compose up -d`. You don't need a pipeline for this — a Makefile or a short shell script per project is enough. **Add observability before adding orchestration.** The most common mistake is reaching for Nomad or Kubernetes when what you actually need is to see what's running and whether it's healthy. Tools like [ServerCompass](https://servercompass.app) let you see all your running services, SSL expiry, and uptime at a glance across multiple hosts — which is often exactly what a NOC dashboard is trying to solve, without standing up a full monitoring stack. **Document your recovery paths as you go.** The operator who migrated to Nomad/Consul/Vault noted that documented recovery paths were a deliberate part of their build. You don't need Vault to document what you do when your database won't start. A plain Markdown file in your repo is enough, and it forces you to think through failure scenarios before they happen. **Automate the toil, not the architecture.** Custom Python automation for deployments sounds useful until you're debugging it at 2am. Automate the things you do every day (deployments, certificate renewals, backups), and keep the things you do rarely (adding a new service, migrating a database) manual and documented. The ratio of automation to documentation should shift toward documentation as the consequences of failure increase. ## When to actually move to a platform The full platform path is worth it when the operational requirements justify it — specifically: - You're running workloads for other people and need SLA-level reliability - You have multiple team members who need controlled access to different services - Your service count has grown to the point where manual coordination of deployments is causing incidents - You need audit trails for compliance reasons If none of those apply, the single-VM or multi-VM Compose approach with good observability and documented runbooks will take you further than most operators think. The homelab builders doing full Nomad/Consul/Vault platforms are often solving for the learning experience as much as the operational need — which is a perfectly valid reason, but different from what most public-service operators need. The gap between "one Compose VM" and "full platform engineering" is real, but it's mostly filled with better habits, not more software. ## Checklist - Split services by failure domain across VMs rather than running everything in one Compose file - Version-control each Compose file and deploy with a simple `git pull && docker compose up -d` - Add observability (uptime, SSL expiry, container health) before reaching for an orchestrator — [ServerCompass](https://servercompass.app) covers this without standing up a monitoring stack - Document recovery steps for every service in a plain Markdown file in the repo - Automate daily toil (deployments, cert renewals, backups) but keep rare operations manual and documented - Only add a scheduler (Nomad, Swarm, etc.) when manual coordination is actively causing incidents - Build recovery paths explicitly — do not assume you will remember what to do when a service fails at 2am - Review your maintenance surface every few months: every component you add is something that can break on a Sunday night --- ## Home-server app managers keep leaking abstraction at Docker, Compose, TrueNAS app, and Samba boundaries Source: https://deployhandbook.com/blog/compare/home-server-app-managers-docker-compose-truenas-samba Tags: docker-compose, portainer, truenas, samba, app-management Home-server app managers promise a friendlier interface over Docker, Compose, and storage services — but operators keep hitting the same wall: the UI covers 90% of what you need and leaves the last 10% completely inaccessible. Here is what those friction points look like in practice and how to plan around them. Home-server app managers promise a friendlier interface over Docker, Compose, and storage services — but operators keep hitting the same wall: the UI covers 90% of what you need and leaves the last 10% completely inaccessible. ## The abstraction leak problem Every app manager that sits on top of Docker, Compose, or a NAS app catalog is making a bet: that the fields it exposes in its form or template cover what you will actually need. That bet fails more often than the marketing suggests. The pattern appears repeatedly across home-server communities. An Unraid user wants to leave XML-style Docker templates behind and move to Portainer and Compose workflows. Reasonable enough — Compose files are portable and readable. The hesitation is not philosophical; it is operational. Will existing container networking survive the migration? Will volumes and bind mounts stay intact? The Unraid template system has opinions baked in, and Portainer has different opinions, and the gap between those opinions is where data loss or broken service discovery happens. A TrueNAS user running the official Palworld app hits a different version of the same problem. The app form exposes the common Docker configuration fields — image, environment variables, restart policy — but omits the REST API port. That port is not cosmetic; it is how external tooling communicates with the server. The form cannot expose every possible field, so it picks a subset, and whatever falls outside that subset is either inaccessible or requires dropping back to a raw Docker run command that now lives outside the app manager's state tracking. Samba is the third case. A thread on r/selfhosted asked a straightforward question: should Samba stay on bare metal or move behind a container or a UI like TrueNAS Shares? The native Samba documentation is terse and the configuration format is unforgiving. An app manager or container layer would make it easier to set up — but it adds another abstraction to debug when a share stops mounting, and most NAS UIs still require you to understand the underlying smb.conf semantics to diagnose permission problems. ## Where Portainer and Compose fit Portainer is a solid choice when your goal is visibility and control over existing Docker infrastructure. It does not replace Compose — it wraps it. You can deploy stacks from Compose files directly through the Portainer UI, which means your configuration stays in a format that is readable outside Portainer and can be version-controlled. The risk when migrating from a template-based system like Unraid is network configuration. Unraid templates often assume the `br0` bridge or custom Docker networks that are created as part of the Unraid setup. When you import those workloads into Portainer, the network references may not resolve correctly if Portainer is managing a different Docker daemon context or if the networks were created outside Compose. Before migrating, list your current Docker networks (`docker network ls`), document which containers use which network, and verify those networks will exist in the target environment before you start the migration. For new deployments, Compose files give you the cleanest escape hatch. If the app manager ever fails you, the Compose file still works from the command line. Write your stacks in Compose format even when you are managing them through a UI. ## TrueNAS app catalog limitations TrueNAS Scale's app catalog (backed by Helm charts) and TrueNAS Core's plugin system both solve the installation problem. They do not solve the configuration problem for anything non-standard. The Palworld case is representative: the form exposes what the chart author decided to expose. If you need a field that was not considered — a secondary port, a specific mount path, an environment variable with a non-obvious name — you are stuck. The options are: wait for the chart to be updated, use a community chart instead of the official one, or abandon the app catalog and deploy the container directly with `docker run` or a Compose file on the same host. Deploying outside the catalog is not dramatic, but it does mean the app manager no longer knows that container exists. Tools like [ServerCompass](https://servercompass.app) help here — it lets you see all your running services at a glance, regardless of whether they were deployed through a catalog, Compose, or a bare `docker run`. When your app manager's state and your actual container state diverge, a dashboard that reads directly from the Docker socket gives you the ground truth. For TrueNAS specifically, if you need to expose a port the app form does not show, the path is: note the app's Docker network name (visible in `docker network ls` when the app is running), then deploy a sidecar container on that network that handles the port forwarding or additional configuration. It is more moving parts, but it keeps the base app managed by TrueNAS while adding the missing capability alongside it. ## Samba: container or bare metal The honest answer for Samba is that containerising it does not remove the complexity — it relocates it. You still need to configure user mappings, share paths, and permissions. The difference is where you edit those settings and how you debug them. Bare-metal Samba has one advantage: the documentation, while terse, is authoritative and complete. Every configuration option is in the man page. There is no translation layer between what you write and what smbd reads. Containerised Samba (using images like `dperson/samba` or `servercontainers/samba`) gives you restart policies, isolation, and easy version pinning. The trade-off is that bind mounts for the share directories need to match the UID/GID mappings inside the container, and getting that wrong produces permission errors that are harder to trace than native Samba errors because you have to look at both the host filesystem permissions and the container user mappings simultaneously. For a home server where Samba is serving a handful of users and a few share paths, bare metal is easier to operate and debug. If you are running Samba alongside other services that are already containerised and you want a unified restart and update strategy, the container approach is reasonable — just budget extra time for the initial UID/GID setup. ## Checklist - Before migrating from Unraid templates to Portainer/Compose, run `docker network ls` and document which networks each container uses; recreate those networks in Compose before starting the migration. - Write all new deployments as Compose files, even when managing them through a UI — this preserves the escape hatch if the UI fails. - When a TrueNAS app form does not expose the field you need, check if a community Helm chart for the same app includes it before dropping to a bare `docker run`. - If you deploy containers outside the app catalog, use a Docker-socket dashboard like [ServerCompass](https://servercompass.app) to keep visibility over all running services in one place. - For missing ports in TrueNAS apps, deploy a sidecar container on the same Docker network rather than abandoning the catalog-managed app entirely. - For Samba, prefer bare metal on home servers with a small number of shares; only containerise if you need a unified restart/update strategy across your stack. - When containerising Samba, resolve UID/GID mappings before writing share paths — this is the most common source of permission errors. - Test share mounts from a client before calling the Samba setup complete; many configuration errors are silent until an actual mount attempt.