# ServerCompass — full published content > 83 articles. Source: https://servercompass.app --- ## Auto Deploy When Your Reverse Proxy Runs in Docker Source: https://servercompass.app/blog/auto-deploy-when-your-proxy-runs-in-docker Published: 2026-07-22 Tags: auto-deploy, nginx-proxy-manager, docker, webhooks, reverse-proxy, traefik If your reverse proxy runs in a container, Auto Deploy webhooks used to die at connection refused — the gateway only listened on localhost. Server Compass v1.34.1 lets you say where your proxy runs, so Nginx Proxy Manager, a Traefik container, or a cloudflared tunnel can reach it. You already have a reverse proxy, and it already works. Nginx Proxy Manager sits in a container, terminates TLS for a dozen hostnames, and has been doing it flawlessly for a year. So when you turn on Auto Deploy, you do the obvious thing: add one more proxy host, point it at the webhook gateway, save. Then GitHub delivers the push event and nothing happens. The delivery log shows a red X. Your proxy logs say `connection refused`. You check the gateway container — running. You check the port — listening. You re-read every field twice. Nothing in your setup looks wrong, and technically nothing is. The culprit is one line of Docker networking. The Auto Deploy gateway published its port on `127.0.0.1` only, which is exactly right when your proxy runs on the server itself. But inside a bridge-networked container, `127.0.0.1` is *the container*, not the host. Your proxy dials localhost, finds nothing listening there, and hands GitHub a 502. ## What changed Server Compass v1.34.1 asks you where your proxy actually runs, and binds the gateway to match. Pick **Proxy runs in Docker** and the gateway becomes reachable from your containers — so Nginx Proxy Manager, a Traefik container you manage yourself, or a containerized tunnel can forward webhooks without you hand-editing a compose file on the server. ![Activate Auto Deploy modal showing Route ownership set to Existing reverse proxy and the new Gateway access section with Proxy runs in Docker selected](/app-screenshots/servercompass-1.34.1-docker-proxy-gateway-access.jpg) ## How it works in practice ### Tell Server Compass who owns the route Open your app, go to **Auto Deploy**, and click **Set up Auto Deploy**. Under **Route ownership** you get three choices: - **Server Compass–managed Traefik** — Server Compass attaches the gateway route to your existing `traefik-public` network. - **Existing reverse proxy** — you route your hostname to the gateway address shown after the check. - **Stable tunnel** — a named Cloudflare Tunnel (or equivalent) forwards to the gateway. The new **Gateway access** section appears for the last two. Managed Traefik doesn't need it: Server Compass puts the gateway on Traefik's own network, so there's no host port to reach across. ### Choose where your proxy runs Two options, and the difference is the bind address printed under each one: - **Proxy runs on the server host** — `127.0.0.1`. Localhost only. This is the right pick for Nginx, Caddy, or a tunnel installed directly on the VPS, and it's what every existing setup keeps doing. - **Proxy runs in Docker** — `0.0.0.0`. All IPv4 interfaces. This is the pick for Nginx Proxy Manager, a Traefik or Caddy container, or a `cloudflared` container on a separate Docker network. Choosing the Docker option surfaces an amber warning, and it's worth taking seriously: *this publishes the plain-HTTP gateway port on every IPv4 interface.* The gateway itself still verifies GitHub's signature on every request, but the port is now visible beyond loopback. Restrict it — see below. ### Read the gateway address off the readiness check Click **Check server**. The readiness list confirms Docker Engine and Docker Compose are available, then shows the **Gateway port** with the exact address your proxy needs — `0.0.0.0:42457`, for example. **Public GitHub delivery** stays pending; it's checked after install, once the route exists. ![Server readiness check passing with Gateway port bound to 0.0.0.0:42457 and routing guidance for the proxy container](/app-screenshots/servercompass-1.34.1-docker-proxy-readiness-check.jpg) Underneath the checks is the instruction that saves the most time. In your proxy container, route your webhook hostname to an address the *container* can use to reach the server on that port — the host's LAN address, or the Docker bridge gateway (commonly `172.17.0.1`). Do **not** point the proxy at `0.0.0.0`; that's a bind address, not a destination. And preserve the raw request body and GitHub headers, or signature verification fails on a payload that was helpfully re-encoded in transit. ### Confirm the binding after activation Once it's live, the **Deployment runtime** card on the server's Deployment tab carries a **Gateway bind** tile showing the active address and port, sitting alongside Version, Route mode, Queue, Disk, and Active targets. When a webhook stops arriving six months from now, that tile answers "what is this thing actually listening on?" without an SSH session. ![Auto Deploy card showing the setup states Installed, Routed, Hooked, Verified and Active with the GitHub hook returning 202](/app-screenshots/auto-deploy-10-auto-deploy-active.jpg) A successful delivery in GitHub's webhook log looks the same as it always did — a `202` response, and a deployment starting on the server while the desktop app stays closed. ![GitHub webhook delivery log showing a 202 response from the Auto Deploy gateway](/app-screenshots/auto-deploy-09-github-delivery-202.jpg) ### Lock the port down One caveat that catches people: the gateway port is published by Docker, and Docker writes its own iptables rules ahead of `ufw`. A `ufw deny` on that port will look correct and do nothing. Filter it in the `DOCKER-USER` chain instead, dropping traffic that arrives on your public interface: ```bash sudo iptables -I DOCKER-USER -i eth0 -p tcp --dport 42457 -j DROP ``` Swap `eth0` for your public interface and `42457` for your gateway port. Container-to-host traffic from your proxy still works; the outside world gets nothing. If your provider offers a network firewall (Hetzner, DigitalOcean, AWS security groups), closing the port there is equally effective and survives a rules flush. ## Before vs after | Situation | Before v1.34.1 | With v1.34.1 | |---|---|---| | Proxy installed on the server host | Works | Works, unchanged — `127.0.0.1` is still the default | | Proxy in a bridge-networked container | `connection refused`, no supported fix in the UI | Pick **Proxy runs in Docker**, gateway binds `0.0.0.0` | | Finding the address to route to | Inferred from the compose file over SSH | Printed by the readiness check before you activate | | Checking what's live later | Route mode only | **Gateway bind** tile on the Deployment runtime card | | Securing the exposed port | On you, undocumented | Inline warning plus guidance to restrict it | ## Who benefits most **Nginx Proxy Manager users.** NPM is the most common way to run a proxy in a container, and it was the setup most likely to fail before. It now works with one radio button. **Homelab and multi-app servers.** If one box serves eight apps behind a single containerized proxy, you were never going to install a second proxy on the host just for webhooks. **Tunnel users running `cloudflared` in Docker.** Same networking problem, same fix — the tunnel container reaches the gateway over the bridge instead of a loopback it can't see. ## Also in this release: one home for server-side services Auto Deploy's runtime and the monitoring agent now live together under `/opt/server-compass/agents/`. If you already had Auto Deploy running from the old path, the update moves it for you: the directory is relocated, the compose file is rewritten to match, and the containers are rebuilt in place. Your configuration, webhook secrets, and deployment history come along. There's nothing to do and nothing to reconfigure — you'll only notice if you go looking for the files. ## Try it Update to v1.34.1, open the app you deploy from GitHub, and click **Set up Auto Deploy**. Pick **Existing reverse proxy**, choose **Proxy runs in Docker**, run the server check, and route your hostname to the address it prints. The next `git push` deploys itself — through the proxy you already trust, with your SSH port still closed. New to Auto Deploy? Start with the full walkthrough: [How to auto-deploy to your VPS on every git push](/blog/auto-deploy-vps-on-git-push). --- ## How to Auto-Deploy to Your VPS on Every Git Push (No Exposed SSH) Source: https://servercompass.app/blog/auto-deploy-vps-on-git-push Published: 2026-07-21 Tags: auto-deploy, github, ci-cd, cloudflare-tunnel, webhooks, vps Turn on Auto Deploy in Server Compass v1.34.0 and every push to your branch deploys itself — through an always-on worker on your server, with the desktop app closed and your SSH port private. A full step-by-step setup using a Cloudflare Tunnel. Every developer who self-hosts hits the same wall eventually. You make a change, commit it, push to GitHub — and then you have to go *do the deploy*. Open the desktop app, find the app, click **Redeploy**, wait. Miss that last step and production quietly keeps serving yesterday's code. The usual fixes all have a catch. Keep your laptop awake and the app open so it can watch the repo? Fragile. Wire up a CI runner that SSHes into your box? Now you're poking a hole in your firewall and handing a deploy key to a third party. Poll the repository every few minutes? Slow, wasteful, and still needs something running. Server Compass v1.34.0 removes the wall. Turn on **Auto Deploy** for a GitHub-connected app and every push to your tracked branch deploys the exact commit on its own — through an always-on worker that lives on *your* server. Your computer can be asleep. Your SSH port can stay private. GitHub just sends a signed webhook over HTTPS, and your server does the rest. This tutorial walks through the whole setup end to end, using a Cloudflare Tunnel as the public entry point. ![Auto Deploy active in Server Compass showing the setup states Installed, Routed, Hooked, Verified, Active with the GitHub hook returning 202 and the last deployed commit](/app-screenshots/auto-deploy-10-auto-deploy-active.jpg) ## What you'll need - **Server Compass** with a **Pro** license (Auto Deploy runs a licensed always-on service). - An app deployed from a **GitHub** repository that **builds on your VPS**. Auto Deploy tracks a branch of a real GitHub-connected app — it isn't available for registry-only or upload deployments. - **A public HTTPS address GitHub can reach.** GitHub's webhooks come from the public internet, so it needs *some* way in. You have three options, and you pick one during setup: - **Server Compass–managed Traefik** — attach the gateway route to your existing `traefik-public` network. - **Existing reverse proxy** — route a hostname you already control to the loopback gateway port. - **Stable tunnel** — a named Cloudflare Tunnel (or equivalent) that forwards to the gateway. This is the one we'll use because it works even on servers with no public inbound ports at all. ## Step 1 — Deploy an app from GitHub, building on the VPS Auto Deploy attaches to an existing app, so start by creating one from a GitHub source if you haven't already. In **Create Your App**, choose **GitHub** as the source, pick your account and repository, and select the branch you want to track — `main` in this example. Server Compass auto-detects the framework and, if there's no `docker-compose.yml`, generates one for you. ![Create Your App wizard with GitHub selected as the source, a repository chosen, branch set to main, and an auto-generated Docker config](/app-screenshots/auto-deploy-01-select-github-repository.jpg) On the next step, set **Build Location** to **Build on VPS**. This matters: Auto Deploy redeploys by building the tracked commit *on the server*, so the server-side Compose stays authoritative. You can wire up Auto Deploy after the first manual deploy succeeds. ![Configure and Deploy step with Build Location set to Build on VPS, highlighted as the recommended option](/app-screenshots/auto-deploy-02-choose-build-on-vps.jpg) ## Step 2 — Open Deployments and start Auto Deploy setup Once the app is live, open it and switch to the **Deployments** tab. You'll see the source repository, the tracked branch, and an **Auto Deploy** card that reads: *"Deploy every push to `main` through an always-on worker on this server. Server Compass does not need to stay open."* Click **Set up Auto Deploy** to begin. ![App detail page on the Deployments tab, showing the source repository and the Set up Auto Deploy button](/app-screenshots/auto-deploy-03-open-deployments-start-setup.jpg) ## Step 3 — Choose how GitHub reaches your server This is the heart of the setup. The **Activate Auto Deploy** dialog opens with the reminder that *GitHub uses public HTTPS while your server's SSH stays private.* Enter the public hostname GitHub will call — here, a `testwebhook` subdomain — and choose your **Route ownership**. We're picking **Stable tunnel**. Below that, the **Server readiness** check confirms Docker Engine and Docker Compose are available and shows the **gateway port** the receiver listens on (a loopback address like `127.0.0.1:42315`). Note that port — you'll forward your tunnel to it. Public GitHub delivery is checked after install. ![Activate Auto Deploy dialog with Stable tunnel selected and a passing server readiness check showing the loopback gateway port](/app-screenshots/auto-deploy-04-choose-stable-tunnel-copy-gateway.jpg) ## Step 4 — Point a Cloudflare Tunnel at the gateway If you chose Stable tunnel, hop over to your Cloudflare dashboard and open **Networking → Tunnels** (under Zero Trust). Cloudflare Tunnel lets a public hostname reach a service running on `localhost` with no open inbound ports on your server at all. ![Cloudflare dashboard sidebar with Networking expanded and Tunnels highlighted](/app-screenshots/auto-deploy-05-cloudflare-networking-tunnels.jpg) In your tunnel, **Add a published application route**. Set the public hostname to the same subdomain you entered in Server Compass (`testwebhook` on your domain), and set the **Service URL** to the loopback gateway from Step 3 — `http://127.0.0.1:42315`. Cloudflare configures DNS for you. Save the route. ![Cloudflare Add published application dialog mapping the testwebhook subdomain to the local gateway service URL](/app-screenshots/auto-deploy-06-cloudflare-published-app-route.jpg) ## Step 5 — Activate Back in Server Compass, click **Activate Auto Deploy**. It installs the deployment target policy on the server and wires everything together. ![Activate Auto Deploy dialog showing the installing the deployment target policy progress bar](/app-screenshots/auto-deploy-07-activate-installing-policy.jpg) Server Compass then **creates the GitHub webhook for you** — no fiddling in repo settings. If you open your repository's **Settings → Webhooks**, you'll see a freshly created `push` webhook pointing at your tunnel hostname, with a green check for its last delivery. ![GitHub repository Webhooks settings showing the push webhook Server Compass created, with a successful last delivery](/app-screenshots/auto-deploy-08-github-webhook-created.jpg) ## Step 6 — Verify the connection Send a test delivery. In the webhook's **Recent Deliveries**, a healthy setup returns **HTTP 202** — GitHub reached your tunnel, the receiver verified the signature, and the job was accepted. (The webhook path carries a secret, so keep this URL private.) ![GitHub webhook Recent Deliveries tab showing a push delivery that returned a 202 Accepted response](/app-screenshots/auto-deploy-09-github-delivery-202.jpg) Back on the Auto Deploy card, the status walks through **Installed → Routed → Hooked → Verified → Active**. The *Deploy automatically on push* toggle is on, the webhook URL is shown with its secret masked, and you get a one-line health summary: **GitHub hook active** with the last response code, and the **last deployed** commit hash. A reminder note confirms the important part — GitHub must reach your hostname over HTTPS, but SSH can stay private. ## Step 7 — Push, and watch it deploy itself Now the payoff. Make a change, commit, and push to `main`. You don't touch Server Compass — you can close it entirely. Open the **Deployment History** later and you'll see a **Webhook Deploy** entry for your commit, marked **Success**, with the live logs of the build and container start. The telling detail: it's tagged **"Desktop was offline."** The deploy ran without the app open, driven entirely by the always-on worker on your server. ![Deployment history showing a successful Webhook Deploy for the pushed commit, tagged Desktop was offline, with live deployment logs](/app-screenshots/auto-deploy-11-webhook-deployment-history.jpg) Load the app and the change is live — new commit, new content, served from the exact commit you pushed. ![The deployed demo app in a browser showing the updated content, confirming the push triggered an automatic deploy](/app-screenshots/auto-deploy-12-deployed-app-updated.jpg) ## How it works under the hood The design keeps the risky parts far away from anything sensitive: 1. On each push, **GitHub sends a signed webhook** over HTTPS to your public hostname. 2. A **lightweight receiver verifies the signature** and queues the job. This public-facing piece has **no access to your Docker socket or a shell** — the worst it can do is enqueue a build request for a repo you already connected. 3. The **always-on worker** on your server picks up the job, checks out the exact commit, and redeploys the app — the same build path as a manual deploy. 4. Because the build happens on the server, **your SSH port never has to be reachable from the internet.** GitHub only ever talks to the HTTPS hostname. That's why it works with the desktop app closed and your machine asleep: nothing about the deploy depends on your computer. ## Managing the deployment service The Auto Deploy card and the Deployment Service view give you the controls you'll actually reach for: - **Rotate secret** — the signing secret is stored on the server and never displayed. Rotate it any time; Server Compass updates the GitHub webhook to match. - **Pause / Resume** — stop deploying on push without tearing anything down, then switch it back on. - **Emergency stop** — instantly stop accepting new webhook deployments while keeping the queue and full history intact. - **One shared history** — webhook deploys and the deploys you start by hand land in the same Deployments list. - **Remove** — uninstall Auto Deploy from a server in a single step. Your deployment history is preserved. ## Troubleshooting reachability If deliveries don't reach 202: - **Fully isolated networks still need a self-hosted runner or stable tunnel.** A hostname alone isn't enough — DNS, TLS, firewall/NAT, and proxy routing all have to line up so GitHub's request lands on the gateway. - Re-run **Check server** in the Activate dialog to confirm Docker, Compose, and the gateway port are healthy. - Make sure your tunnel's Service URL points at the **exact** loopback gateway port Server Compass showed, and that the public hostname matches on both sides. - Your reverse proxy or tunnel must **preserve the raw request body and GitHub headers** — the signature is computed over the unmodified payload. ## Wrapping up You now have a proper push-to-deploy pipeline that doesn't cost you a managed platform, a CI runner, or an exposed SSH port. Push to `main`, and the commit ships itself. If you're building out a fuller pipeline, these guides pair well with this one: - [Self-Hosted CI/CD: GitHub Actions + Your VPS](https://servercompass.app/blog/self-hosted-cicd-github-actions-vps) — when you want a build step in the cloud before deploy. - [Stop Blind Pushes to Your GitHub Repos](https://servercompass.app/blog/github-deploy-push-confirmation) — add a confirmation gate to GitHub-triggered deploys. - [Cloudflare Tunnel Feels Random? A Reliability Checklist](https://servercompass.app/blog/cloudflare-tunnel-random-reliability-checklist) — keep the tunnel you set up here rock-solid. Auto Deploy ships with Server Compass v1.34.0. Update the app, open any GitHub-connected app's **Deployments** tab, and click **Set up Auto Deploy** to turn your next `git push` into a deploy. --- ## Move Your EasyPanel Apps to Your Own VPS — Without Taking the Old One Down Source: https://servercompass.app/blog/migrate-easypanel-apps-to-your-vps Published: 2026-07-19 Tags: migration, easypanel, docker, import, v1.33.0 Server Compass v1.33.0 connects over your existing SSH login, takes a read-only inventory of your EasyPanel projects, and copies supported apps plus their MySQL, MariaDB, and PostgreSQL data into isolated staging — while EasyPanel keeps serving traffic. You moved to EasyPanel because it made Docker feel manageable. A tidy dashboard, a few clicks, and your Ghost blog, your WordPress site, and that little static page were all running behind clean domains. No hand-written compose files, no wrestling with Traefik labels at midnight. Then the reasons to move on started stacking up. Maybe you want a server you own end to end. Maybe you're consolidating three boxes into one. Maybe you just want your apps managed by the same tool you use for everything else. Whatever the reason, the moment you actually plan the move, the same cold thought shows up: those apps are *live*. Real visitors are hitting them right now. The WordPress database has orders in it. Copy the wrong folder, dump a database at the wrong moment, or point a domain at a half-built box, and you don't have a migration — you have an outage. So the move keeps sliding to "some quiet weekend" that never comes. ## What changed Server Compass v1.33.0 introduces **Migrate from EasyPanel** — a guided way to move your EasyPanel apps and their databases onto a VPS you control, without stopping EasyPanel or touching your live data. You start a Server Migration, pick EasyPanel as the source, and Server Compass connects over the SSH login you already use. It takes a **read-only inventory** of your EasyPanel projects — services, domains, environment variables, ports — and then copies each supported app into **isolated staging on unused ports**. Your current setup keeps serving traffic the entire time. Nothing is switched over until you decide it is. This first release is a **preview**: it's built to stage your apps safely so you can inspect the copied result today. Flipping production traffic to the migrated apps is the next step on the roadmap. ![Server Compass migration source picker showing provider tiles with real brand logos — RunCloud, Server Compass, Render, EasyPanel marked Preview, Coolify and Dokploy](/app-screenshots/01-migration-source-picker.jpg) ## How it works in practice The whole thing runs as a six-step wizard — Select Source, Scan Server, Review Apps, Deploy & Migrate, Other Items, and Review & Clean Up — so you always know where you are and what happens next. ### See exactly what will move, before anything changes After you choose EasyPanel and run the scan, Server Compass shows you a **Discovered Services** list: every EasyPanel project it found, each labelled so there are no surprises. A project is marked **Ready** when it can be imported cleanly, or flagged for review, snapshot-only, or blocked when it needs a closer look. You pick exactly which ones to bring across — select all, or just the app you care about today. This is the part that turns a scary migration into a boring one. Instead of guessing what's on the server, you're reading a checklist of what's about to happen. ![Discovered Services step listing three EasyPanel projects — ghost, rawhtml and wordpress — all marked Ready to import into isolated Server Compass staging](/app-screenshots/02-easypanel-discovered-services.jpg) ### Bring the database along — and verify it Copying an app's files is the easy half. The half that actually keeps you up at night is the data. Migrate from EasyPanel copies your **MySQL, MariaDB, and PostgreSQL** data into the staged app and verifies it landed, so you can confirm the migration worked *before* you rely on it. Because this is explicit staging, Server Compass is careful about the order: EasyPanel stays live, persistent files and databases are copied into isolated target storage, and domains are deliberately **not** activated. You'll see a clear "Prepare data first" prompt rather than the tool quietly reaching for your live setup. Under the hood it walks through copying files, starting an isolated target database, dumping the source, and restoring into the staged copy — each step reported in plain language as it runs. ![Deploy and Migrate step showing an explicit-staging notice that EasyPanel remains live while persistent files and databases are copied into isolated target storage, with a Prepare data first action](/app-screenshots/03-easypanel-deploy-prepare-data.jpg) ### Watch it come up in staging Once staging kicks off, each project deploys onto its own unused port and you watch it move from Pending to Deploying to **Running**, with data migration marked Done alongside it. Your apps are now standing up on the new server in isolation — reachable for you to inspect, invisible to the outside world, and completely separate from what EasyPanel is still serving. If one project's data migration hits a snag, it's called out on its own line with a Retry option, so a single hiccup doesn't force you to restart the whole run. ![Deploy and Migrate step with EasyPanel projects staged — ghost Running and rawhtml Deploying — and data migration completed for ghost and wordpress](/app-screenshots/04-easypanel-staging-projects.jpg) ### Your secrets never end up in a log Environment variables are where migrations quietly leak. Migrate from EasyPanel encrypts each value the moment it's read, and those values never show up in logs, error messages, or on screen. The stuff that would ruin your week if it landed in a screenshot stays sealed. ## Before vs after | Moving off EasyPanel by hand | Migrate from EasyPanel | |---|---| | SSH in and hunt down every project's files and volumes yourself | One read-only scan lists every project and labels what's ready | | Dump and restore each database manually, hoping the versions line up | MySQL, MariaDB, and PostgreSQL data copied into staging and verified | | Take the old app down (or risk data drift) while you copy | EasyPanel keeps serving traffic; nothing is stopped | | Copy env vars around in plaintext and pray none leak | Values encrypted on read, never printed to logs or screen | | Find out it's broken after you've already cut the domain over | Inspect the fully staged result before any cutover | ## Who benefits most **People outgrowing a managed panel.** If you're bumping into EasyPanel's ceiling — pricing, resource limits, or just wanting full control of the box — this gets your apps onto your own VPS without a rebuild-from-scratch project. **Anyone consolidating servers.** Running apps across a couple of EasyPanel boxes and want them under one roof? Stage them side by side on the target server and confirm each one before you commit. **The cautious operator with live data.** If your apps have real users and a real database, the isolated-staging model is built for you: you get to see the migrated copy working before it ever touches production traffic. ## Try it Update to Server Compass v1.33.0, open a server, and start a **Server Migration** — you'll find EasyPanel waiting in the source picker, now alongside Render, RunCloud, Coolify, and Dokploy with their real logos. Scan, review what's ready, and stage a project into isolation. You'll be able to inspect the whole thing running on your own VPS before you decide anything is permanent — which is exactly how a migration should feel. --- ## Stop Hoping Your Servers Are Backed Up — See It in One Place Source: https://servercompass.app/blog/see-every-server-backup-in-one-place Published: 2026-07-17 Tags: backups, snapshots, disaster-recovery, security, v1.32.0 Server Compass v1.32.0 adds the Backup Protection Center: one overview of every server marked protected, manual-only, or not protected — with in-app scheduling, portable snapshots, selective folder backups, and a restore that can't lock you out of SSH. You have a few servers. You *think* they're backed up. But if someone asked you right now — which ones, how often, where the backups actually live, and when the last one succeeded — you'd have to open each server, dig through a couple of different screens, and piece it together. And that nagging one you spun up in a hurry last month? You genuinely can't remember whether you ever set anything up for it. That's the real problem with backups. It isn't that they're hard to run. It's that "protected" is a status you can never quite see, so you're left hoping instead of knowing. And the one time it matters — the day a disk dies or a bad deploy wipes a volume — hoping is not where you want to be. ## What changed Server Compass v1.32.0 introduces the **Backup Protection Center** — a single overview that shows the protection status of your Server Compass app data and every VPS in one place. Each one is marked **protected**, **manual-only**, or **not protected**, with its latest backup or snapshot and a direct path to set up anything that's missing. No more opening servers one at a time to reconstruct the picture. You open one screen and the gaps are obvious. ![Server Compass Server Backups screen showing backup schedule, retention window, and storage destination for a VPS](/app-screenshots/feature-server-backups.jpg) ## How it works in practice ### See every server's protection at a glance The overview is the point. Protected servers show their last successful backup and next scheduled run; manual-only servers tell you they'll only be backed up when you remember to; not-protected servers stand out so you can fix them before you need them. When something's missing, there's a direct link to set it up rather than a hunt through menus. You also get backup health without drilling in: the last result, the next scheduled run, the chosen storage destination, and what's actually included — all readable at a glance. ### Schedule server backups without leaving the app Turn automatic backups on for a server and pick the cadence: **hourly, daily, weekly, or monthly**, at the time you choose. Set how many to keep — the latest **3, 7, 14, or 30** — and where they go. Retention and destination are decisions you make once, in the app, instead of hand-rolling a cron job and an rsync script you'll have to maintain forever. ### Choose in-place recovery or a portable snapshot Two shapes of protection, for two different bad days. A **standard backup** is for in-place recovery — something broke on this server, roll it back. A **portable snapshot** is for moving or rebuilding a VPS entirely — pick it up and stand the whole setup back up somewhere else. The Center makes the difference explicit so you pick the right one instead of guessing. ![Server Compass Server Snapshots screen for creating a portable snapshot of a VPS setup](/app-screenshots/feature-server-snapshots.jpg) ### Back up the folders that live outside your apps Your managed apps aren't the only things worth keeping. That config directory you edited by hand, a logs folder, some files a script drops on disk — with **selective backup** you add any server folder you choose, and when it's time to restore you can pick individual folders rather than restoring everything. ![Server Compass selective backup screen letting you add and choose individual server folders to include in a backup](/app-screenshots/feature-selective-backup.jpg) ### Manage where backups actually land Destinations and passphrases for app-data backups, server backups, cloud snapshots, and device sync now live on one dedicated screen — including **SFTP and pCloud** targets — so you can see and manage everywhere your data goes from a single place. ![Server Compass backup destinations screen showing SFTP and pCloud storage targets](/app-screenshots/backup-destinations-sftp-pcloud.jpg) ### A restore that can't lock you out of SSH This is the safeguard that makes the rest worth trusting. You can include firewall and login-protection settings in a server backup — but on restore, Server Compass does **not** apply them automatically. It places them in a review folder with instructions and leaves them for you. That means a stale or bad security rule from an old backup can never silently reactivate and lock you out of your own server. Recovery shouldn't be the thing that takes you offline. ## Update on your terms, too v1.32.0 also puts you in charge of how Server Compass itself updates. Choose how updates appear — a subtle sidebar notice, the full update window automatically, or silent checks. Let it **download and install automatically** and apply on quit, or kick off a background download and keep working while the sidebar shows progress and flips to "Relaunch to update" when it's ready. And set your own check schedule — periodically while running, only at launch, or on demand. Security-critical fixes can still reach you even after a Pro license's included update period ends. ## Before vs after | Backups before | With the Backup Protection Center | |---|---| | Open each server and stitch the status together yourself | One overview: protected, manual-only, or not protected at a glance | | Hand-write cron jobs and rsync scripts to schedule | Pick hourly/daily/weekly/monthly and a retention window in the app | | Scheduled backups and snapshots split across two screens | Scheduled backups and portable snapshots managed together | | Guess where each server's backups are stored | One destinations screen for every target and passphrase | | A restored firewall rule can silently lock you out | Security settings land in a review folder, never auto-applied | ## Who benefits most **Anyone running more than one server.** The moment you have three VPSes, "is everything backed up?" stops being answerable from memory. The overview answers it in a glance. **Operators with real data to lose.** If a database or a config folder going missing would ruin your week, per-server scheduling plus selective folder backups mean the important stuff is covered on a cadence you chose. **The safety-first admin.** The no-auto-apply rule on firewall and login settings is built for the person whose worst fear isn't losing data — it's getting locked out of the box during the recovery itself. ## Try it Update to Server Compass v1.32.0 and open the **Backup Protection Center**. Find the server you're least sure about, read its status, and click straight through to set up a schedule, a destination, and a portable snapshot. The goal isn't more backup busywork — it's getting to the point where "are my servers protected?" is a question you can answer by looking, not by hoping. --- ## Give clients a private status page for their app Source: https://servercompass.app/blog/client-status-portals-for-your-apps Published: 2026-07-13 Tags: client-portals, status-page, agencies, app-management Give a client a private, read-only status page for a single app — scoped to what you choose, on your own domain, without handing over a login to your server. A client emails at 9pm: "Is the site down? It feels slow." You open a terminal, SSH into the server, run `docker ps`, tail a few logs, take a screenshot, and reply. Ten minutes spent on a question the client could have answered themselves in five seconds — if only they had somewhere safe to look. The usual fix is worse than the problem. You either keep fielding "is it up?" messages by hand, or you hand the client a login to your control panel — and now the person who just wanted a green light can see every other app on the server, restart the wrong container, or wander into a database that isn't theirs. ## A private status page for one app — and nothing else Client Portals give a client a read-only status page for a single app. They open a link, see whether the app is healthy, and check its recent metrics — with no account, without touching the rest of your server, and without seeing anything you didn't choose to share. The page is scoped to exactly one app. Everything else on that server — your other clients, your own projects, the machine itself — stays invisible. ![The client-facing status page showing a Healthy app with uptime, CPU, memory, container storage, network throughput, and a last-hour performance chart](/app-screenshots/client-portal-status-page.jpg) ### Turn it on for one app, in a guided flow From the app you want to share, open **Configure client portal**. Before anything installs, Server Compass runs a readiness scan on the server: it checks your license, that Docker and Compose are available, that the runtime images are pinned, that the CPU architecture is supported, and that there is at least 512 MB of disk and 256 MB of memory free. Anything that needs attention is listed with a plain label, so you fix it before setup rather than in the middle of it. When the checks pass, Server Compass installs a small portal runtime at `/opt/servercompass/client-portal`, configures the public HTTPS route, and verifies HTTPS before the link ever goes live. ### Choose exactly what the client can see and do By default a portal is view-only: the client sees status and basic metrics and nothing else. From the **Permissions** list you decide how far that goes: - **View status** and **View metrics** are always on — that is the point of the page. - **View recent logs** lets the client see recent output when something looks off. - **Restart**, **Start**, and **Suspend application** give the client one-tap control over that single app. Hand a non-technical client a pure status page. Give a technical client the ability to restart their own app at 2am instead of paging you. Every action a client takes is written to a per-client activity log, and the controls wear an "audited actions" badge so nobody forgets they are real. ![The Share client portal dialog configuring brand name, logo, accent color, a 30-day expiry, an optional passcode, and per-app permission checkboxes](/app-screenshots/client-portal-create-branding-permissions.jpg) ### Make it look like yours, on your own domain A client-facing page shouldn't say "Server Compass." Under **Portal branding** you set a brand name, upload a logo, and pick an accent color — the logo is resized locally and stored with that link. Point a hostname like `status.yourclient.com` at the portal and it serves over HTTPS: through managed Traefik automatically, or through your existing reverse proxy if you run one. ![The client status page scrolled to owner-enabled application controls with Start, Restart, and Suspend buttons and an audited-actions badge](/app-screenshots/client-portal-status-page-controls.jpg) ### Keep every link under control The private link grants access without a login, so the safeguards matter: - **Expiry** — a link can expire after 1, 7, 30, 90, or 365 days. Pick the shortest span that fits the engagement. - **Optional passcode** — add a second factor on top of the private link. - **Secrets stay on your device** — links live in your computer's system keychain, and your server credentials never leave the encrypted vault. - **Rotate, revoke, or remove** any link from one place, with a read-only preview so you can see exactly what the client sees. If a client suspends their app, you find out immediately: the app is flagged **Suspended by client** in your own dashboard, so there is never a mystery about why something stopped. ![The owner's Server Compass app list showing an app flagged Suspended by client after a client used a portal control](/app-screenshots/client-portal-app-suspended-by-client.jpg) ## Before and after | Answering "is my app up?" | Before Client Portals | With Client Portals | | --- | --- | --- | | Client checks the app | Emails you; you SSH in and reply | Opens a private link and reads "Healthy" | | What access you hand over | A control-panel login that sees everything | A read-only page scoped to one app | | How it looks | A generic tool's UI | Your name, logo, and color on your domain | | Client restarts their app | They page you; you do it | One tap, if you allow it — fully audited | | Revoking access | Change passwords and hope | Rotate or revoke the link in one click | ## Who gets the most out of this - **Agencies and freelancers** hosting client apps: replace the "is it up?" thread with a branded link, and let clients restart their own app without opening a ticket. - **MSPs running many clients on one server**: give each client a portal scoped to just their app, with a per-client activity log for accountability. - **Anyone handing off a project**: leave the client a status page they can trust — on your domain, that expires when the engagement does. ## Try it Update to v1.30.0, open the app you want to share, and choose **Configure client portal**. A couple of minutes later you'll have a branded, private, expiring status page — and one less "is it up?" message to answer by hand. --- ## Move a running app to another server, data and all Source: https://servercompass.app/blog/move-apps-between-your-servers Published: 2026-07-13 Tags: migration, multi-server, docker, server-management Clone an app and its data from one server you manage to another with a guided wizard — the original keeps running until you point DNS at the new server. Sooner or later an app outgrows its server. The box is too small, the host is too expensive, or you want it sitting closer to your users. Moving it should be a shrug. Instead it's an evening: `docker save` the image, `scp` it across, `rsync` every named volume (and hope you remembered them all), hand-copy the compose file, recreate the environment variables, re-add the domains and SSL, and pray nothing depended on a path you forgot. Miss one volume and the app comes up empty. Fat-finger a bind mount and it comes up broken. And the whole time, the version your users are hitting is the one you're trying to move away from. ## Clone an app to another server you manage Server Compass now lists itself as a migration source. Choose **Server Compass** in Migration and it clones an app — its configuration and its data — from one server you manage to another. The original keeps running the entire time; you cut over only once you've watched the copy work. ![The Migrate-from-another-service picker showing Server Compass as a new source to clone an app to another Server Compass server, alongside Render, Coolify, and Dokploy](/app-screenshots/migration-provider-selection.jpg) ### Start from the app you want to move Open the app's menu on the dashboard and choose **Migrate to other Server Compass server**. That drops you straight into the transfer wizard with the app already selected — no hunting through settings. ![An app's context menu open on the dashboard with Migrate to other Server Compass server highlighted](/app-screenshots/move-app-between-servers-app-menu.jpg) ### Follow the wizard: app, target, review, go The wizard moves through five plain steps — **Choose app, Choose target, Review, Migrate, Done**: 1. **Choose the app** on the source server. 2. **Choose the destination** — any other server you've connected to Server Compass. 3. **Review what transfers.** Server Compass runs a preflight and shows you exactly how many data volumes and how many domains it found, flags any issues before you commit, and tells you when an app was built locally so its image has to be streamed to the target rather than pulled. 4. **Start the migration** and watch a live log as the data and configuration move across. Two toggles keep you in charge of the copy. **Copy data volumes** brings the app's data along. **Re-create domains and Traefik routing** rebuilds the routing on the destination — while your DNS stays pointed at the source, so nothing cuts over by surprise. ### Cut over on your own schedule When the migration finishes, the app is running on the new server and the original is still running on the old one. Nothing is live until you say so. Verify the copy, then point your DNS at the new server when you're ready. If something looks wrong, you've lost nothing — the source never stopped serving traffic. ## Before and after | Moving an app to a new server | The manual way | With Server Compass | | --- | --- | --- | | Move the image | `docker save` / `scp` / `docker load` | Streamed automatically when needed | | Move the data | `rsync` each volume by hand | One "Copy data volumes" toggle | | Recreate config and domains | Hand-copy compose, re-add domains and SSL | Rebuilt on the target from a preflight | | Risk to the live app | You're racing your own downtime | Original keeps running until you cut over | | Knowing you got everything | Hope | Preflight lists volumes, domains, and issues | ## Who gets the most out of this - **Upgrading to a bigger box** — clone the app to the new server, test it, then flip DNS. - **Changing providers or regions** — move from one host to another without rebuilding by hand. - **Splitting workloads** — pull a heavy app off a shared server and onto its own. - **Keeping a warm spare** — clone an app to a second server as a ready-to-go copy. ## Try it Update to v1.30.0, open the app you want to move, and choose **Migrate to other Server Compass server**. Pick the destination, review what transfers, and start — your app lands on the new server with its data, while your users keep hitting the old one until you decide to cut over. --- ## Bring Your Own SSL Certificate for Any Domain Source: https://servercompass.app/blog/bring-your-own-ssl-certificate Published: 2026-07-10 Tags: ssl, custom-certificates, domains, https, traefik Server Compass now lets you upload an OV or EV certificate from your own certificate authority for any domain — validated, installed, and served over HTTPS without touching a terminal. Let's Encrypt is the right default for most domains, and Server Compass has issued and renewed those certificates automatically for a long time. But not every domain gets to use it. Maybe your company bought an OV or EV certificate so the browser shows the verified organization name. Maybe a client, a bank, or a compliance requirement mandates a specific certificate authority. Maybe you're serving an internal domain that Let's Encrypt can't validate at all. Until now, those cases dropped you out of the visual workflow and back into a terminal. You'd SSH in, paste PEM blocks into files, hand-edit Traefik or nginx config, wire up the certificate resolver, reload the proxy, and hope the chain order was right — because a missing intermediate certificate looks fine in your browser and broken in everyone else's. Every renewal meant doing it all again from memory. ## What changed You can now bring your own SSL certificate for any domain, right inside Server Compass. When you add a domain, you choose between Let's Encrypt and a custom certificate you provide. Server Compass validates the files, installs them on your server, wires up the reverse proxy, and shows the certificate's real status afterward — no SSH session, no config editing, no guesswork about the chain. ![Add New Domain modal with the Custom certificate (OV/EV) option selected, showing the Certificate, Private Key, and CA Bundle upload fields](/app-screenshots/custom-ssl-01-add-domain-choose-and-upload.jpg) ## How it works in practice ### Pick your certificate type when you add the domain The Add Domain screen now offers two clearly labeled choices: **Let's Encrypt (automatic)** — free, issued and renewed automatically by Traefik — or **Custom certificate (OV/EV)** — bring a certificate from your own CA like Sectigo or DigiCert, where renewal is manual. Choosing custom reveals three upload fields: **Certificate (PEM)**, **Private Key (PEM)**, and **CA Bundle / Intermediate Certificates**. You don't have to copy-paste long PEM text. Each field has an **Upload file** button, so you can pick the `.pem`, `.crt`, or `.key` files your certificate authority sent you straight from your computer. And the note under the private key field says exactly what happens to it: it's sent directly to your server over SSH and never stored on the machine you're working from. ### Get the certificate validated before you commit The moment your certificate and key are in, Server Compass checks them. It confirms the certificate matches the private key, that it actually covers the domain you're adding, and that it hasn't expired — the three mistakes that otherwise only surface after your site is already live and broken. ![Add New Domain modal showing a green Certificate looks good card listing the issuer, expiry date, and covered domains, above a summary of what happens on submit](/app-screenshots/custom-ssl-02-certificate-validated.jpg) When everything lines up, you get a green **Certificate looks good** card that reads back what you uploaded: who it was issued to, the issuing certificate authority, the expiry date, and every domain the certificate covers. Below it, Server Compass tells you exactly what it's about to do — apply Traefik labels to your container, verify the app is responding on its port, set up the reverse proxy, install the certificate on the server, and enable the automatic HTTPS redirect. You approve a plan, not a black box. ### See custom certificates at a glance afterward A custom certificate has one property Let's Encrypt doesn't: it won't renew itself. So the SSL Certificates list makes that impossible to forget. Custom domains show a **Custom** badge next to their status, along with the issuing authority, the real expiry date, and a plain reminder that Traefik serves the uploaded certificate but does not auto-renew it — replace it before it expires. ![SSL Certificates list showing a domain card labeled Custom with active status, manual-renewal wording, expiry date, and the issuing certificate authority](/app-screenshots/custom-ssl-03-ssl-list-custom-card.jpg) Sitting right next to your Let's Encrypt domains — which still say "renews automatically" — the difference is obvious. You always know which certificates you're responsible for and when the next one is due. ### Switch an existing domain over at any time This isn't only for brand-new domains. Open any domain's SSL settings and you'll find a **Use Custom Certificate** button to upload a certificate for a domain that's currently on Let's Encrypt. Already on a custom certificate and renewal time has come around? **Replace Certificate** swaps in the new files. Changed your mind entirely? **Use Let's Encrypt** hands the domain back to automatic management. You're never locked into the choice you made when you first added the domain. ## Before vs after | Task | Before | Now | | --- | --- | --- | | Install a custom certificate | SSH in, paste PEM blocks into files, edit Traefik config by hand | Upload three files in the Add Domain screen | | Verify the chain and key match | Reload the proxy, open the site, hope it works everywhere | Validated before you submit, with a clear pass/fail | | Know when it expires | Set your own calendar reminder and pray | Expiry date and a manual-renewal badge in the SSL list | | Renew | Repeat the whole manual process from memory | Replace Certificate, upload the new files | | Switch back to Let's Encrypt | Undo the config by hand | One button | ## Terminals that stay put The same release fixes a smaller annoyance that adds up over a long session. Terminal tabs are now persistent: when you open a terminal, run something, then jump to another screen to check a container or edit a domain, the session is still there — and still running — when you come back. Long-running commands keep going in the background even when the terminal isn't the active window, so a build, a migration, or a log tail no longer dies the moment you look away. ## Who benefits most **Teams under compliance requirements.** If your security policy or a client contract dictates a specific CA, OV, or EV certificate, you can finally satisfy it without leaving the tool that manages everything else. **Agencies running client sites.** Some clients arrive with a certificate already purchased. Now onboarding that domain is an upload, not a manual server-configuration task you have to schedule and document. **Anyone with an internal or wildcard certificate.** Domains that Let's Encrypt can't or shouldn't issue for — internal hostnames, wildcard certs bought in bulk — now get the same one-screen setup as everything else. ## Try it Update to the latest version of Server Compass, open a domain, and choose **Custom certificate** when you add it or from its SSL settings. Upload your files, watch them validate, and let Server Compass handle the proxy and the install. Your own certificate, served over HTTPS, without a single line of config edited by hand. --- ## Give Coding Agents Scoped Access to Your VPS Source: https://servercompass.app/blog/ai-access-coding-agents Published: 2026-07-03 Tags: AI Access, MCP, coding agents, VPS management, Server Compass Server Compass v1.28.0 adds AI Access, a local token-secured MCP connection that lets coding agents inspect and operate your VPS through scoped permissions instead of raw SSH credentials. When you are already working inside a coding agent, server operations become a context switch. You ask the agent to change a deployment, then you leave the conversation to open a terminal, remember which VPS has the app, run a Docker command, copy logs back, and decide what to do next. The agent can help with the code, but the server still lives behind a separate SSH workflow. The risky shortcut is to paste credentials into the agent or give it a broad shell command. That may get one task done, but it also gives the tool more access than it needs. Server work needs narrower boundaries: an agent should be able to inspect a server, deploy an app, or read logs without receiving raw SSH keys or saved secrets. ## What Changed AI Access gives coding agents a local, token-secured MCP connection to Server Compass, so you can let an agent inspect and operate your VPS from the tools you already use without handing over raw server credentials. ![AI Access token setup showing scoped permissions and server selections](/app-screenshots/ai-access-setup-token-permissions-server-scope.jpg) ## How It Works In Practice ### You Turn On A Local MCP Server Open Settings and switch to **AI MCP**. The **AI Access (MCP)** panel starts a local endpoint on your machine, usually `http://127.0.0.1:52700/mcp`. The endpoint stays local, so your coding agent talks to Server Compass on your computer instead of connecting directly to every VPS. That separation matters. Server Compass keeps the SSH keys, passwords, saved environment values, and vault secrets inside the desktop app. The agent gets tools and responses. It can ask Server Compass to list servers, inspect apps, read logs, or run allowed operations, but it does not need the underlying credentials. ### You Create A Token With The Right Scope Each connected AI tool gets its own token. When you create one, you choose permission tiers such as **Read**, **Operate**, **Deploy**, and **Danger**. You can also restrict the token to selected servers, so a staging agent can work on a tutorial VPS without touching production. This is the difference between useful automation and blind trust. A read-only token can answer questions about server state. An operate token can restart containers or inspect app health. A deploy token can create or update deployments. Dangerous actions are separated so destructive requests require explicit approval before they run. ![AI Access Activity tab showing allowed and denied MCP calls](/app-screenshots/ai-access-activity-log-allowed-denied.jpg) ### You Copy Setup Instructions For Your Tool The setup panel includes ready-made install snippets for **Claude Code**, **Codex CLI**, **Gemini CLI**, **OpenCode**, **Cursor**, **Windsurf**, and **VS Code**. You can choose the full `servercompass` tool name or the shorter `sc` alias before copying the config. That means you do not have to hand-write MCP JSON or remember the exact header format. Pick your tool, choose install or uninstall, copy the snippet, and the agent can start calling the Server Compass tool set through the token you selected. ![AI Access setup panel with install snippets for coding tools](/app-screenshots/ai-access-coding-tools-setup-instructions.jpg) ### Your Agent Can Inspect And Act Once connected, the agent can ask Server Compass for structured server context instead of guessing from pasted logs. It can list servers, list apps on a VPS, read app status, search templates, inspect deployments, manage domains, update environment values, and operate Docker apps through Server Compass. In practice, this lets you keep a deployment conversation in one place. You can ask the agent what is running on a tutorial VPS, whether a Ghost app is healthy, which templates are available, or what needs to happen before deploying a WordPress test app. ![AI agent using Server Compass MCP tools to list servers and apps](/app-screenshots/agent-list-servers-list-apps-mcp-tools.jpg) ### Server Work Becomes Part Of The Coding Session When the agent has the right token, it can move from diagnosis to action. For example, it can deploy a WordPress app through Server Compass, follow the deployment state, and report back in the same conversation. You still keep the permission boundary: the action runs through Server Compass, the request is audited, and dangerous operations do not bypass confirmation. ![OpenCode agent deploying WordPress through Server Compass MCP tools](/app-screenshots/agent-deploy-wordpress-via-mcp.jpg) ## Before Vs After | Workflow | Before | After | | --- | --- | --- | | Check what is running | Open Server Compass or SSH, then paste context back into the agent | Ask the agent to list servers and apps through Server Compass MCP | | Share access | Paste logs, commands, or credentials into a chat | Create a scoped token with the exact permission tier needed | | Connect a tool | Manually assemble MCP config and headers | Copy the ready-made setup snippet for your coding tool | | Deploy from a conversation | Leave the agent, deploy manually, then return with results | Let the agent call approved Server Compass deployment tools | | Review what happened | Reconstruct actions from terminal history | Read the AI Access activity log with status, timing, client, and server | ## Who Benefits Most Solo developers can keep server work inside the same coding session without turning their agent into a full shell with permanent access. You get help investigating and deploying, while Server Compass keeps the credentials and server state behind a controlled tool boundary. Teams with staging and production servers can create separate tokens for separate jobs. A docs or QA agent can read staging. A deployment-focused agent can receive deploy permission on one server. Production can stay restricted until you intentionally grant access. Anyone experimenting with coding agents gets a safer way to test server automation. Instead of asking an agent to invent SSH commands from memory, you expose a known Server Compass tool surface with permission checks, activity logs, and confirmations for destructive operations. ## Try It Update to Server Compass v1.28.0, open **Settings → AI MCP**, turn on **AI Access**, create a scoped token, and copy the setup snippet for your coding tool. The next time you are debugging or deploying from an agent session, you can ask it to inspect your VPS through Server Compass instead of switching back to raw SSH. --- ## Self-Host an AI Agent on Your VPS in One Click Source: https://servercompass.app/blog/self-host-ai-agent-one-click Published: 2026-06-10 Tags: ai-agent, self-hosted, hermes, release, v1.27.0 Server Compass v1.27.0 deploys Hermes Agent to your VPS in one click — your own OpenAI-compatible gateway, a web dashboard reachable through an SSH tunnel, and chat platforms wired in from the same window. If you have ever tried to stand up your own AI agent — not a chatbot script, but something that holds memory across conversations, installs skills, and responds in Telegram or Discord without you babysitting it — you know how it goes. You spin up a VPS. You pip-install some agent framework. You configure model providers one credential at a time. You write a tiny FastAPI wrapper to expose an HTTP gateway. You realize the web dashboard you wanted is now exposed to the public internet, so you bolt on an nginx reverse proxy. You drop a Telegram bot token into a YAML file you'll lose track of in two weeks. At every step the question shifts from *what should my agent do?* to *how do I keep this thing alive?* ## What changed Server Compass v1.27.0 adds **Hermes Agent** — Nous Research's open-source agent runtime — as a one-click app template. Deploy it from the same wizard you use for Postgres or n8n, and Server Compass gives you a full management UI for everything the agent does: its profiles, its providers, its skills, its memories, its sessions, and its dashboards. You stop running a Python project on a VPS and start running an agent the way you run any other service. ![Hermes Agent dashboard inside Server Compass with the Tunnel button highlighted, showing the remote dashboard on port 9119 and Gateway API on port 8642](/app-screenshots/hermes-agent-dashboard-tunnel.jpg) ## How it works in practice ### Deploy from a template — no Python required In Server Compass, **App Templates** now includes Hermes Agent under self-hosted AI. Click deploy, pick a server, and the agent comes up as a Docker Compose project with the API gateway, dashboard, and persistent volumes pre-wired. The first-time **Setup wizard** walks you through binding the Nous Portal account, pasting in your model API keys, and connecting chat platforms — three things you would otherwise hand-edit across multiple config files. ### Run multiple profiles in one container Open the **Profiles** tab and you see each agent profile listed with its own state. Profiles are isolated: each one keeps its own skills, memory store, and session history. Spin up one profile for your personal assistant, another for a support bot, another for a sandboxed experiment. Start, stop, and switch between them without touching the underlying container. ### Mix providers, switch models from a dropdown The **Models** tab is where you tell the agent which AI to call. The screenshot above shows `anthropic/claude-opus-4.6` active in draft, with a custom provider being registered through the **Opencode (OpenAI-compatible)** template — just a Name and a Base URL. Layer in OpenAI, Anthropic, vLLM, Ollama — or anything that speaks the OpenAI chat completions API — and route between them per profile. No code changes, no container rebuild. ### Wire up Telegram, Discord, Slack, WhatsApp The **Channels** tab gives you the same dropdown experience for chat platforms. Pick Telegram, paste your bot token, and the agent starts answering. Add Discord by selecting a guild. Each channel is bound to a profile, so the same agent body can serve multiple inboxes with different personas. ### Reach the dashboard through an SSH tunnel — without exposing port 9119 to the internet Hermes ships with a web dashboard for talking to your agent directly. By default it binds to `0.0.0.0:9119` inside the container, but you would rather not publish that to the public internet. The screenshot above shows the alternative: a green **Tunnel** button next to *Dashboard remote :9119*. One click opens a secure SSH tunnel from your laptop to the container, with basic-auth credentials pulled straight from the `.env` file. Same for the Gateway API on `:8642`. Your dashboard is reachable from your machine and nothing else. ### Install skills and browse memory from the UI The **Skills** tab lists installable agent skills with credential prompts for each — install one and it asks for the right credentials inline. **Memories** and **Sessions** are full browsers: every long-term memory the agent has stored, every conversation it has had, with the ability to rename or delete sessions. No more grepping JSON in a volume mount to figure out what your agent remembers. ### Quick fixes for the things that break The **Quick Fix** panel exposes one-click resolutions for the issues you will actually hit: **Rotate Key** regenerates the gateway API key, **Reset Creds** wipes and re-issues dashboard basic auth, **Fix Perms** corrects ownership inside the data volume, and **Audit** runs a health check. None of these require SSH-ing in. ## Before vs After | Step | Without Hermes Agent | With Server Compass v1.27.0 | |---|---|---| | Choose a runtime | Read three repos, pick one, hope it is maintained | Pick Hermes from the App Templates list | | Install | `git clone`, build a Dockerfile, hand-write compose | Click deploy, get a working container | | Add API keys | Edit `.env`, restart container | Paste in the Setup wizard | | Expose dashboard safely | nginx + basic auth + Let's Encrypt + DNS | Click **Tunnel** | | Connect Telegram | Find webhook docs, hand-edit YAML | Pick Telegram, paste token | | Add a model provider | Edit config, restart, hope it parses | Pick template, save, restart from UI | | Recover from broken creds | SSH, edit files, restart | Click **Reset Creds** | ## Who benefits most **Indie developers experimenting with agentic workflows.** You want to try Hermes today, not in three days. Deploy, point an OpenAI-compatible client at the gateway, and start building. **Privacy-conscious users.** Your agent's API keys, conversation history, and long-term memory live on a VPS you control. Nothing routes through a third-party agent host. **Anyone running multiple agents.** Profiles let you experiment without spinning up new containers per project. One Hermes deployment, many independent agent identities. ## Try it Update Server Compass to v1.27.0, open **App Templates**, search for **Hermes Agent**, and deploy. The Setup wizard walks you through the rest — and the **Tunnel** button on the Dashboard tab gets you a secure web UI in one click. --- ## Move Render Apps to Your Own VPS Without Rewriting the Dockerfile Source: https://servercompass.app/blog/import-render-apps-to-your-vps Published: 2026-06-03 Tags: migration, render, docker, import, v1.26.0 Server Compass v1.26.0 connects to your Render API key, pulls env vars, domains, secret files, and build commands, and generates a Docker plan you can deploy in one click — plus firewall lockout protection for custom SSH ports. You moved to Render because deploying felt easy. Push to a branch, watch the build, click a domain into place. It was nice — until the monthly bill stopped looking like one service and started looking like a small AWS invoice. Or the cold starts on the Starter plan started cutting into your launch. Or the company VPS sitting at home, idle, started feeling like a missed opportunity. The plan was simple: move off. Then you opened Render's dashboard, expanded the environment variables tab, and started counting. Twelve env vars on the web service. Three secret files. Two custom domains, each with its own DNS, redirect, and SSL setup. A managed Postgres on the side. A Redis. A build command you wrote eight months ago and now can't quite remember the flags for. The "move it tomorrow" plan turned into a "block out a full Saturday and pray" plan. ## What changed Server Compass v1.26.0 introduces **Import from Render** — connect a Render API key, pick the service you want to move, and you get a ready-to-deploy Docker plan on your VPS in one wizard. Env vars, custom domains, secret files, runtime, build commands, and dependency hints all come through in a single import. The Docker Compose file, Dockerfile, port config, and project name are auto-generated. Companion managed services (Postgres, Redis, Key-Value) are detected and surfaced as warnings so the data layer doesn't get forgotten. ![Server Settings Migration tab with six migration sources where Render is selected and the Import from Render button is active](/app-screenshots/server-migration-screen.jpg) ## How it works in practice ### Connect a Render API key (once) Open Server Compass, pick the server you want to deploy onto, and head to **Server Settings → Migration**. Pick **Render** from the source tiles — RunCloud is the other live option; Coolify, Dokploy, Laravel Forge, and Raw VPS are queued for upcoming releases. Click **Import from Render** and paste a Render API key into the connection panel. The key gets stored in your local encrypted vault, not in any cloud config. You can connect more than one Render account: switch between workspaces from the picker, disconnect any of them with a single click, and run multiple imports from the same wizard without re-pasting keys. ### Pick the service, analyze the plan ![Import from Render modal showing Render API key connection picker and service dropdown with a selected web_service - docker service ready to analyze](/app-screenshots/render-migration-selected.jpg) Once a key is connected, the Service dropdown lists every web service, background worker, and static site on the selected owner. Choose the one you want to move and click **Analyze Service**. Server Compass reads the Render config in one request: environment variables (including the values, not just the keys), custom domains with their HTTPS settings, secret files, runtime, build command, start command, and the source repo or container image. From that, it builds a deployment plan — and it tells you, before you commit, which path it's going to take: - **GitHub build**, if the service is wired to a repo. The generated Compose file points at the repo and branch Render was already tracking. The build command and runtime get translated into a Dockerfile that matches what Render was running. - **Paste-compose**, if the service is image-based. The generated Compose pulls the same image Render was using. You'll still need registry access if it's a private image, but that's the only manual step. Companion managed services — a Postgres database, a Redis instance, a Key-Value store — get listed as migration warnings on the analysis screen. They're not silently dropped or silently included; you decide whether to self-host them as Docker services alongside the app or keep them on Render for now. ### Continue into the Stack Wizard Hit continue and the Stack Wizard opens with everything pre-filled: project name, env vars, port config, Dockerfile (or paste-compose), and the Compose file ready to deploy. Env vars stay in the encrypted local vault until the build step ships them to the server — they don't get written to a tracked file, they don't leak into a public Compose snippet, and they don't sit on disk in plain text. From here it's a normal Server Compass deploy: review the generated files, hit deploy, watch the build logs stream in real time. The first run takes the same amount of time as any other Compose deploy; from then on, the app behaves like every other Server Compass app — redeploys, env-var edits, custom domains, SSL, backups, all wired through the same dashboard. ## Before vs After | Step | Before | With Import from Render | |---|---|---| | Pull env vars | Open Render → Environment → copy each row by hand | One API call, all values in the encrypted vault | | Pull secret files | Download each file from Render, re-upload to the VPS | Imported with the rest of the config | | Translate runtime → Dockerfile | Read Render docs, guess at base image, retest build | Auto-generated Dockerfile matching the Render runtime | | Custom domains | Re-add each domain to the reverse proxy and re-issue certs manually | Pre-filled in the deploy plan | | Companion DB/Redis | Forget one and have the app boot empty on Sunday | Surfaced as warnings before the deploy starts | | Time to a working VPS deploy | A full afternoon, maybe two | The length of one Compose build | ## Who benefits most **Solo founders watching the Render bill creep up** — a single web service plus a managed Postgres on Render is around fifty dollars a month before traffic. The same workload runs on a five-dollar VPS once you're past the Compose file. Import from Render makes the move a wizard step instead of a Saturday. **Agencies moving client apps off shared infrastructure** — every client app you import comes with the same env vars, secret files, and domains it had on Render. Re-deploys, backups, and domains then sit in the same Server Compass dashboard as every other client server. **Devs migrating to homelab hardware** — Render's free tier is generous until your project gets popular. Importing into a homelab VPS keeps the same env vars, the same domains, and the same runtime — no rewriting required. ## Firewall lockout protection — the companion safety net Once your app is on the VPS, you'll likely want to lock down the firewall. v1.26.0 also ships a quiet but important improvement here: **Server Compass now respects your custom SSH port when you enable the firewall**. Before this release, "Enable Firewall" hardcoded port 22 as the allowed SSH rule. If your server ran SSH on a non-standard port (20203, 2222, anything but 22), enabling UFW silently locked you out — the default-deny policy went up, port 22 was the only allowed inbound, and your real SSH connection had nowhere to land. Now the firewall reads your real SSH port from the server settings, refuses to enable UFW if that rule wasn't persisted first, and blocks you from accidentally adding a custom rule that conflicts with the managed SSH port. The SSH rule in the rules list shows a "Protected" shield instead of a delete button, just like port 22 used to. It's not the headline of the release, but it's the kind of fix that turns a 30-minute "console rescue" into a non-event. ## Try it Open Server Compass, switch to a server, and head to **Server Settings → Migration**. Pick Render, paste a key, and click through one service. The whole flow — connect, pick, analyze, deploy — runs in the same wizard you already know. [Download v1.26.0](https://servercompass.app/download) to get Import from Render and Firewall Lockout Protection on your VPS today. --- ## Rename Your Docker Apps Without Breaking Them Source: https://servercompass.app/blog/custom-app-display-names Published: 2026-05-29 Tags: app-management, docker, ux, v1.25.3 Server Compass v1.25.3 introduces friendly Custom App Display Names — replace cryptic project slugs with human-readable labels across every view, while containers, volumes, and folders on the server stay exactly where Docker expects them. You glanced at your Server Compass sidebar this morning and tried to remember which app was the staging copy. `wp-blog-v2-prod`. `wp-blog-v2-staging`. `wp-blog-old`. `wp-blog-archive-2025`. Four entries, two characters of difference between them, and the only way to tell at a glance was to click in and check the domain. You thought about renaming the project. Then you remembered why you stopped doing that: the project slug is baked into the container names, the volume mounts, the bind paths, the Compose service references, and the directory on the server. Renaming the project means breaking every Docker reference your app has, and that's a half-day of regression fixing for the sake of a tidier sidebar. So the slugs stay. So the squinting stays. This is the kind of friction that compounds. You manage one app, the slug doesn't matter — you can read `myblog` and know what it is. You manage twelve apps across three servers and the slugs start blurring together. The team Slack message turns into "the one with `-v2-` in the name", because nobody actually remembers what `wp-blog-v2-prod` does at 9pm on a Friday. ## What changed Server Compass v1.25.3 introduces **Custom App Display Names**. You can now give every Docker app a human-readable name — "My WordPress Blog", "Client A — Staging", "Old archive (don't touch)" — that shows up across the apps list, grid view, table view, and the dashboard header. The original project slug is still right there, just under the friendly name, so containers, volumes, and folders on the server stay matched to a recognizable identifier. Nothing on the server changes; only what you see in the UI changes. ![Server Compass app dashboard header showing a friendly display name 'My WordPress Blog' with the underlying project slug visible underneath](/app-screenshots/custom-app-display-names.jpg) ## How it works in practice ### Set the display name from the Settings tab Pick the app from your dashboard and switch to the **Settings** tab. The **Display Name** field sits near the top, pre-filled with the current project slug. Type whatever you want — emoji included, if you're into that — and save inline. There's no rename operation behind the scenes: no containers stop, no volumes move, no Compose files rewrite. The display name is metadata, stored against the app record, applied at render time. You can change it as often as you want without paying a runtime cost. ### Watch it propagate The friendly name immediately replaces the slug in: - **The apps list (sidebar).** What used to be ten cryptic slugs becomes ten readable labels. - **Grid card view.** The card title is now the display name; the slug sits as a small secondary line. - **Table view.** Same: display name in the primary column, slug as the muted identifier underneath. - **App dashboard header.** When you're inside an app, the page title is the friendly name; the slug appears next to it for unambiguous reference to the server-side resources. The slug never disappears. It's quieter, but it's still there for the moments when you need to match the app to a `docker ps` row or a bind path — exactly the moments where a friendly name wouldn't help. ### Search by either name Type "My Blog" into the search bar — match. Type "wp-blog-v2-prod" — match. The apps search now hits both fields, so muscle memory still works while you transition to the friendlier labels. If a teammate sends you a Slack screenshot with the old slug, you can still paste it into search; if you only remember the friendly name, that also works. ### Clear the name to fall back Empty the field in Settings and save. The app falls back to showing the original slug everywhere. Nothing else changes. There's no destructive action, no migration, no risk — and it means you can experiment with display names without committing to any of them. ## Before vs After | Workflow | Before | With Display Names | |---|---|---| | Tell two prod/staging apps apart at a glance | Hover, click in, read the domain | One look at the sidebar | | Rename a project for clarity | Rename folder → break every container, volume, network reference | Set a display name; nothing on the server moves | | Help a teammate find an app by description | "It's the one with the slug that starts with…" | "It's called My WordPress Blog" | | Onboard a new dev to a 15-app server | Walk through what each slug means | They read the sidebar | | Search by either name | Slug only | Display name OR slug | ## Who benefits most **Agencies running client apps side by side.** Twelve `wp-` apps in the sidebar is twelve apps that look the same. With display names, the sidebar becomes a client roster: "Acme Co — Production", "Acme Co — Staging", "Beta Industries — Live". You stop scanning, you start reading. **Anyone running prod and staging copies of the same app.** The slug difference between `myapp-prod` and `myapp-staging` is small enough that muscle memory occasionally hits the wrong one. The display name difference — bold "Production" vs muted "Staging" — is the kind of distinction that's harder to misread when you're tired. **Devs maintaining an old portfolio of self-hosted apps.** That side project from two years ago has a slug you barely remember. Rename it to "Side project (don't touch unless something breaks)" and the next-you who logs in will know exactly what they're looking at. ## Zero-downtime deploys also got quieter The other big v1.25.3 change isn't a new feature, it's a sharper edge on an old one. **Zero-downtime redeploys now pull the latest code before rebuilding**, just like a standard redeploy — previously you had to remember to redeploy the standard way first if you wanted the new commit. They also respect explicit `container_name` and complex network setups (so the staging build doesn't collide with the live one), sync the latest env file into the staging directory before the new version starts, honor the per-domain SSL setting (HTTP-only domains stop being forced through HTTPS), and combine staging + primary logs in a single stream during the deploy. If you're using zero-downtime as your default redeploy mode, this release closes the last few gaps where the staging path behaved differently from the standard one — the upgrade path is now a strict superset of the simpler redeploy, with no quiet differences to remember. ## Try it Update to v1.25.3, open any app's **Settings** tab, and rename it. The new display name shows up everywhere the slug used to — and your filesystem, containers, and Compose files don't know anything happened. [Download v1.25.3](https://servercompass.app/download) to rename your apps without renaming anything on the server. --- ## Never Lock Yourself Out of Your Server Again Source: https://servercompass.app/blog/firewall-ssh-lockout-prevention Published: 2026-05-23 Tags: firewall, security, ssh, backup, ufw Server Compass now protects your SSH firewall rule from accidental deletion, blocks duplicate port 22 entries, and adds per-config backup passphrases — so critical access paths can't be removed by mistake. There's a particular kind of panic that every server admin knows: you're cleaning up firewall rules, you delete one that looked redundant, and suddenly your SSH session freezes. You just locked yourself out of your own server. The fix involves a console session through your hosting provider's dashboard, if you're lucky — or a full server rebuild if you're not. It shouldn't be this easy to brick your own access. ## What Changed Server Compass v1.25.1 makes it impossible to accidentally remove your SSH access rule from the firewall. The app now protects port 22 at every level — the rule list, the custom rule form, and the delete action — so you can manage UFW freely without ever risking a lockout. ![UFW firewall panel showing protected SSH port 22 with shield icon and live status indicators](/app-screenshots/feature-firewall.jpg) ## How It Works in Practice ### SSH Port Protection The firewall rules panel now marks your SSH access rule (port 22) with a "Protected" badge. The delete button is replaced with a shield icon — there's no way to remove it through the UI, even by accident. If you try to add a custom rule for port 22, the form shows a clear warning: "SSH is managed automatically." This prevents duplicate rules that could conflict with the protected one, and stops you from creating a rule that you might later delete thinking it's redundant — only to discover it was your only SSH path in. Quick Add port shortcut buttons are hidden entirely when UFW is inactive. No point showing port shortcuts when the firewall isn't running — it just creates confusion about whether rules are actually applied. ![Firewall rules showing protected SSH rule with shield badge and inline progress indicators](/app-screenshots/ufw_firewall.jpg) ### Live Status Indicators Adding, deleting, or refreshing firewall rules now shows inline progress on each rule row. Instead of clicking "Delete" and wondering if anything happened, you see a spinner on that specific rule until the operation completes. This is especially useful on slower connections where UFW operations can take a few seconds. ### Root User Protection The user management panel applies the same principle to the root account. A shield icon replaces the delete button for root — you can't accidentally remove the account that owns the system. This mirrors the firewall protection: critical system resources get visual protection, not just a confirmation dialog that you can click through on autopilot. ### Per-Config Backup Passphrases Each S3 storage configuration can now have its own encryption passphrase, with automatic fallback to the global passphrase when a per-config one isn't set. If you back up different servers to different S3 buckets — production to one account, staging to another — you no longer share a single passphrase across all of them. The backup section also got a layout refresh: the server picker is shown by default instead of hiding behind a click, the backup button shows the exact server count ("Back up 3 servers now"), and recent backups are separated into their own card for easier browsing. ![Recent backups section showing per-server backup cards with passphrase and storage configuration options](/app-screenshots/recent_backup.jpg) ## Before vs After | Scenario | Before v1.25.1 | After v1.25.1 | |---|---|---| | Delete an SSH firewall rule | Allowed — risk of lockout | Blocked — shield icon, no delete button | | Add port 22 as a custom rule | Allowed — creates confusing duplicates | Warning message: "SSH is managed automatically" | | UFW is off, port shortcuts visible | Shortcuts shown — misleading | Hidden until UFW is active | | Firewall rule operation in progress | No feedback — is it working? | Inline spinner per rule | | Delete root user | Allowed with confirmation dialog | Blocked — shield icon | | Backup passphrase for multiple S3 configs | One global passphrase for all | Per-config passphrase with global fallback | ## Try It Update to Server Compass v1.25.1. Open the Firewall section and look for the shield on your SSH rule — it's already protected. Then check Cloud Backup settings if you use multiple S3 configurations — the per-config passphrase field is ready to use. --- ## 150+ new self-hostable apps just landed in Server Compass v1.25.0 Source: https://servercompass.app/blog/150-new-self-hostable-apps-v1-25-0 Published: 2026-05-22 Tags: release, templates, self-hosted, v1.25.0, docker, open-source Server Compass just tripled the deploy catalog: 428 one-click templates, up from 239. AI tooling, productivity, finance, dev tools, storage, monitoring — the gap between 'I want to try this self-hosted app tonight' and 'it deploys' just shrank dramatically. The catalog you used to scroll past — "okay, postgres, mysql, redis, ghost, n8n, that's it" — just tripled. Server Compass now ships with **428 one-click app templates**, up from 239 in the previous release. If you've ever found a self-hosted tool you wanted to try, opened Server Compass, searched for it, and shrugged when it wasn't there, that gap is what this release closes. The new entries cover the categories you've been asking for: AI workbenches, productivity suites, project tracking, finance and invoicing, niche developer utilities, storage backends, monitoring stacks, fediverse and social, and a handful of fresh databases. ![Server Compass v1.25.0 launch banner showing the headline '150+ New Apps to Self-Host' above a grid of app logos spanning AI, Productivity, PM & CRM, Finance, Dev Tools, Storage, Monitoring, and Databases.](/app-screenshots/v1-25-0-150-new-apps.png) ## What changed We added **189 new templates** to the deploy catalog, bringing the total to 428. Every new entry ships with the same one-click experience as the originals: pick the template, fill in a few env vars, and Server Compass writes the compose file, generates secrets, opens the right ports, and brings the stack up on your VPS. ## What's new in each category The expansion isn't dumped into one bucket — it's spread across the four parent categories so the filter bar stays useful. Every app below is a one-click deploy; click any name to open its template detail page. ### Productivity & notes [DokuWiki](/templates/dokuwiki), [Anytype](/templates/anytype), [Blinko](/templates/blinko), [SilverBullet](/templates/silverbullet), [Hoarder](/templates/hoarder), [Etherpad](/templates/etherpad), [An Otter Wiki](/templates/otterwiki), [OpenGist](/templates/opengist), [CodiMD](/templates/codimd), [Reactive Resume](/templates/reactive-resume). ### Recipes, habits & home [Grocy](/templates/grocy), [Mealie](/templates/mealie), [KitchenOwl](/templates/kitchenowl), [Habitica](/templates/habitica), [Baby Buddy](/templates/babybuddy), [Homebridge](/templates/homebridge). ### Books, media & reading [BookLore](/templates/booklore), [Calibre Web](/templates/calibre-web), [Ampache](/templates/ampache), [MeTube](/templates/metube), [AzuraCast](/templates/azuracast), [Movary](/templates/movary), [qBittorrent](/templates/qbittorrent), [Bazarr](/templates/bazarr), [Streamflow](/templates/streamflow). ### Communities, social & fediverse [Coral Project](/templates/coralproject), [Storyden](/templates/storyden), [Bluesky PDS](/templates/bluesky-pds), [Redlib](/templates/redlib), [Mumble](/templates/mumble), [Mixpost](/templates/mixpost), [Castopod](/templates/castopod), [Friendica](/templates/friendica), [Pixelfed](/templates/pixelfed), [Lemmy](/templates/lemmy), [PeerTube](/templates/peertube). ### Project management, CRM & ERP [Plane](/templates/plane), [Redmine](/templates/redmine), [Focalboard](/templates/focalboard), [Peppermint](/templates/peppermint), [osTicket](/templates/osticket), [OrangeHRM](/templates/orangehrm), [Frappe HR](/templates/frappe-hr), [SuiteCRM](/templates/suitecrm), [EspoCRM](/templates/espocrm), [Twenty CRM](/templates/twenty-crm), [Freshscout](/templates/freescout). ### Finance, budgeting & invoicing [Akaunting](/templates/akaunting), [Maybe](/templates/maybe), [InvoiceShelf](/templates/invoiceshelf), [DumbBudget](/templates/dumbbudget), [Ezbookkeeping](/templates/ezbookkeeping), [Wallos](/templates/wallos), [Budget Board](/templates/budget-board), [iHateMoney](/templates/ihatemoney), [Bigcapital](/templates/bigcapital). ### E-commerce, tickets & billing [PrestaShop](/templates/prestashop), [Saleor](/templates/saleor), [Medusa](/templates/medusa), [Paymenter](/templates/paymenter), [Hi.Events](/templates/hi-events), [Kimai](/templates/kimai), [Dolibarr](/templates/dolibarr), [LimeSurvey](/templates/limesurvey). ### Identity, auth & secrets [Authorizer](/templates/authorizer), [Casdoor](/templates/casdoor), [Stack Auth](/templates/stack-auth), [Pocket ID](/templates/pocket-id), [HashiCorp Vault](/templates/vault), [Infisical](/templates/infisical). ### Analytics & BI [Ackee](/templates/ackee), [Tianji](/templates/tianji), [Rybbit](/templates/rybbit), [Parseable](/templates/parseable), [Datalens](/templates/datalens), [Argilla](/templates/argilla), [Label Studio](/templates/label-studio). ### Developer tools & APIs [Bugsink](/templates/bugsink), [Marimo](/templates/marimo), [Adminer](/templates/adminer), [Bytebase](/templates/bytebase), [Backrest](/templates/backrest), [ByteStash](/templates/bytestash), [Coder](/templates/coder), [CrowdSec](/templates/crowdsec), [HeyForm](/templates/heyform), [OmniTools](/templates/omni-tools), [Soketi](/templates/soketi), [Drizzle Gateway](/templates/drizzle-gateway), [OpenResty](/templates/openresty-manager), [Cloud9](/templates/cloud9), [Cloud Commander](/templates/cloudcommander), [Kestra](/templates/kestra), [Kaneo](/templates/kaneo), [Kener](/templates/kener), [Ontime](/templates/ontime), [Palmr](/templates/palmr), [Cryptgeon](/templates/cryptgeon), [Apprise API](/templates/apprise-api). ### AI & ML [Crawl4AI](/templates/crawl4ai), [Firecrawl](/templates/firecrawl), [Botpress](/templates/botpress), [OpenHands](/templates/openhands), [Bolt.diy](/templates/bolt-diy), [LibreTranslate](/templates/libretranslate), [Carbone](/templates/carbone), [Docling Serve](/templates/docling-serve), [Flowise](/templates/flowise), [Langflow](/templates/langflow), [Langfuse](/templates/langfuse), [LiteLLM](/templates/litellm), [MindsDB](/templates/mindsdb), [AnythingLLM](/templates/anythingllm), [LobeChat](/templates/lobechat), [LibreChat](/templates/librechat). ### Monitoring & status [Beszel](/templates/beszel), [Checkmate](/templates/checkmate), [Diun](/templates/diun), [Glances](/templates/glances), [Statusnook](/templates/statusnook), [OpenSpeedtest](/templates/openspeedtest), [Scrutiny](/templates/scrutiny), [Zabbix](/templates/zabbix), [Komari Monitor](/templates/komari-monitor), [Statping-NG](/templates/statping-ng), [CheckCle](/templates/checkcle), [Cup](/templates/cup), [UPSnap](/templates/upsnap), [Agent DVR](/templates/agentdvr). ### Storage, files & sharing [AList](/templates/alist), [Cloudreve](/templates/cloudreve), [Garage](/templates/garage), [SeaweedFS](/templates/seaweedfs), [IPFS](/templates/ipfs), [Picsur](/templates/picsur), [DumbPad](/templates/dumbpad), [DumbDrop](/templates/dumbdrop), [AnonUpload](/templates/anonupload), [Pingvin Share](/templates/pingvin-share), [Snapdrop](/templates/snapdrop), [Chibisafe](/templates/chibisafe), [Zipline](/templates/zipline), [FileFlows](/templates/fileflows), [Onetime Secret](/templates/onetime-secret). ### Networking & proxy [Cloudflare DDNS](/templates/cloudflare-ddns), [FlareSolverr](/templates/flaresolverr), [go2rtc](/templates/go2rtc), [Domain Locker](/templates/domain-locker), [Anubis](/templates/anubis) (Anubis is the new AI-bot blocker). ### Bookmarks, reading & trackers [Grimoire](/templates/grimoire), [LinkStack](/templates/linkstack), [Wanderer](/templates/wanderer), [AdventureLog](/templates/adventurelog), [Ryot](/templates/ryot), [YamTrack](/templates/yamtrack), [RSS-Bridge](/templates/rss-bridge), [RSSHub](/templates/rsshub). ### CMS & URL tools [ClassicPress](/templates/classicpress), [Typecho](/templates/typecho), [Shlink](/templates/shlink). ### Mail servers [Stalwart Mail](/templates/stalwart), [Poste.io](/templates/poste-io), [Roundcube](/templates/roundcube). ### File & format tools [ConvertX](/templates/convertx), [VERT](/templates/vert), [Web Check](/templates/web-check). ### Translation, feature flags & sysadmin [Weblate](/templates/weblate), [Tolgee](/templates/tolgee), [Flipt](/templates/flipt), [Unleash](/templates/unleash), [OpenPanel](/templates/openpanel), [Wakapi](/templates/wakapi). ### New databases - [ArangoDB](/templates/arangodb) — multi-model graph + document - [Dragonfly](/templates/dragonfly-db) — Redis-compatible, tuned for modern hardware - [Postgresus](/templates/postgresus) — Postgres backup manager - [RustFS](/templates/rustfs) — S3-compatible object storage written in Rust - [TrailBase](/templates/trailbase) — Firebase alternative built on SQLite + auth + storage ## Before vs after | | Before v1.25.0 | After v1.25.0 | |---|---|---| | Total one-click templates | 239 | **428** | | AI / LLM apps | 4 | 11 | | Finance + invoicing apps | 2 | 8 | | Dev tools | 35 | 89 | | Storage backends | 6 | 25 | | Monitoring stacks | 8 | 23 | The filter bar is the same, the deploy flow is the same — the difference is what shows up in the search bar. ## Who benefits most **The "I want to try this tool tonight" homelab tinkerer.** You read about an open-source alternative on Reddit, you want to deploy it before bed, you open Server Compass — and now there's an actual chance it's already there. **The team escaping a SaaS bill.** If you're migrating off Notion, Trello, ClickUp, Asana, Toggl, FreshBooks, Mailchimp, Intercom, or any of the other "we've outgrown the free tier" stacks, the open-source equivalent is most likely in the catalog now. **Indie builders running their own stack.** Auth ([Authorizer](/templates/authorizer), [Casdoor](/templates/casdoor), [Stack Auth](/templates/stack-auth), [Pocket ID](/templates/pocket-id), [HashiCorp Vault](/templates/vault), [Infisical](/templates/infisical)), email ([Stalwart Mail](/templates/stalwart), [Poste.io](/templates/poste-io), [Roundcube](/templates/roundcube)), analytics ([Ackee](/templates/ackee), [Tianji](/templates/tianji), [Rybbit](/templates/rybbit), [Parseable](/templates/parseable)), and AI tooling ([Langfuse](/templates/langfuse), [LiteLLM](/templates/litellm), [Flowise](/templates/flowise)) — the modern indie-SaaS toolchain is one Server Compass install away from running on your own VPS. ## Try it Open Server Compass, hit **Browse Templates**, and watch the count in the corner click over to 428. Search for the tool you were going to look up later. It's probably already there. [Browse the full template catalog →](https://servercompass.app/templates) --- ## 11 New App Templates and a Redis Admin Built Into Your Database Tab Source: https://servercompass.app/blog/new-app-templates-inline-redis-admin Published: 2026-05-15 Tags: templates, redis, self-hosted, database, traefik, domain-routing Deploy GoatCounter, Linkding, CyberChef, and eight more self-hosted apps in one click. Plus, browse Redis keys and run commands without leaving the Database tab. Setting up a self-hosted app should take five minutes, not an afternoon. But if you've ever tried to deploy GoatCounter for analytics, or Linkding for bookmarks, or CyberChef for data transforms, you know the drill: find the right Docker image, figure out the environment variables, map the ports, cross your fingers on the volume mounts, and debug why it won't start. Repeat eleven times if you want a proper homelab. Meanwhile, every time you need to check a Redis key or flush a cache, you're opening a separate terminal, remembering the connection string, and running `redis-cli` by hand — even though your database tab is right there. Server Compass v1.24.4 fixes both problems at once. ## What Changed Eleven new one-click app templates join the library, covering analytics, bookmarks, search, security tools, developer utilities, networking, and backup. And the Database tab now has a built-in Redis admin — browse keys, inspect values, and run commands without leaving the app. ![App dashboard showing deployed containers with status indicators and domain routing badges](/app-screenshots/feature-app-dashboard.jpg) ## How It Works in Practice ### One-Click App Templates Each template ships with the right Docker image, pre-configured environment variables, correct port mappings, and sensible volume mounts. Pick an app, choose your server, click deploy. The eleven new templates span six categories: - **GoatCounter** — privacy-friendly web analytics without cookies - **Linkding** — fast bookmark manager with tags and auto-archiving - **Whoogle** — ad-free, self-hosted Google search proxy - **CyberChef** — encode, decode, encrypt, and parse data in your browser - **PrivateBin** — encrypted pastebin where the server never sees your content - **Mailpit** — local SMTP server for testing transactional emails - **Gotenberg** — convert HTML, Markdown, and Office docs to PDF on demand - **LibreSpeed** — self-hosted internet speed test - **ntfy** — push notifications from any script that can `curl` - **PairDrop** — AirDrop-style file sharing across devices on your network - **Duplicati** — encrypted, scheduled backups to S3, Backblaze, Google Drive, and more Every template includes post-deployment notes specific to that app — what to configure first, which ports to open, and common gotchas. ![Template library showing available self-hosted apps with one-click deploy buttons](/app-screenshots/feature-templates.jpg) ### Inline Redis Admin The Database tab already detected your Postgres and MySQL containers. Now it picks up Redis, Valkey, and KeyDB services too — showing credentials, the connection string, and a new "Open Admin" button on each card. Click it and a query editor opens right inside the tab. Browse keys by pattern, inspect values (strings, hashes, lists, sets), and run arbitrary Redis commands. No separate tool, no terminal session, no remembering which port you mapped. Redis, Valkey, and KeyDB containers are detected automatically. If your stack pairs Postgres with Redis, both show up as separate cards with their own credentials. ![Redis connection card in the Database tab showing connection details and admin tools](/app-screenshots/connect-apps-02-modal-setup-redis-url.jpg) ### Smarter Domain Routing Every app card now shows a route badge next to its URL. A green "Traefik" badge means the route is verified and traffic is flowing. Amber "Needs review" means the Traefik label setup looks incomplete. Red "Network issue" means the container can't be reached on the expected port. Hover any badge for the full diagnostic. This replaces the old workflow of SSHing in, running `docker inspect`, checking Traefik labels manually, and hoping you read the YAML right. Apps that route through Traefik labels without published ports — a common pattern for reverse-proxy setups — now correctly resolve their domain, container name, and target port across both the App detail and Domain Configurations screens. ![Domain configuration showing SSL certificates and routing status for connected domains](/app-screenshots/feature-domain-manager.jpg) ## Before vs After | Task | Before v1.24.4 | After v1.24.4 | |---|---|---| | Deploy GoatCounter | Find image, write compose, configure env vars, debug ports | One click from the template library | | Check a Redis key | Open terminal, find connection string, run `redis-cli` | Click "Open Admin" on the Database tab | | Know if Traefik routing works | SSH in, `docker inspect`, read labels, check network | Glance at the route badge on the app card | | Deploy 11 common apps | 11 separate research-and-configure cycles | 11 clicks | ## Who Benefits Most - **Homelab builders** expanding their stack — pick from proven templates instead of debugging compose files from GitHub READMEs - **Dev teams** running Redis alongside Postgres — manage both from the same tab without switching tools - **Anyone using Traefik** for reverse proxy — see at a glance which routes are healthy and which need attention ## Try It Update to Server Compass v1.24.4 and open the Templates section to see all eleven new apps. Deploy one, then check your Database tab — if you're running Redis, the admin panel is already there. --- ## Stop Blind Pushes to Your GitHub Repos Source: https://servercompass.app/blog/github-deploy-push-confirmation Published: 2026-05-12 Tags: github, deployment, github-actions, safety Server Compass now shows you exactly what files will be committed to your GitHub repository before any deploy push happens — so you never get a surprise commit on the wrong branch again. Every team that uses GitHub Actions for deployment has a moment of dread: watching a workflow file get pushed to the wrong branch, or realizing the commit already happened before you could review what changed. When your deployment pipeline commits files directly into your repository through the GitHub API, one misclick can trigger a cascade that's harder to untangle than the original deployment. Server Compass v1.24.2 puts a simple gate between you and that mistake. ## What Changed You now get a confirmation dialog before Server Compass pushes any workflow file or Dockerfile to your GitHub repository. Instead of a silent commit that happens behind the scenes, you see exactly what's about to change — and you decide whether it goes. ![Push confirmation dialog showing the target repository, branch, and list of files about to be committed](/app-screenshots/feature-github-deploy.jpg) ## How It Works in Practice ### The Confirmation Dialog When you trigger a GitHub Actions deploy flow that would commit files via the GitHub API, a modal appears before anything is pushed. It shows three things: the exact repository receiving the commit, the target branch, and every file that will be created or modified. This is not a generic "are you sure?" prompt. You see the payload — the workflow YAML, the Dockerfile, whatever the deploy step needs to write — and you can back out cleanly if something looks wrong. ### Smart Skip for Unchanged Files Not every deploy needs a fresh commit. If the workflow YAML on GitHub is already identical to what Server Compass would push, the confirmation is skipped entirely. The deploy step moves on without bothering you, because there's nothing to decide. This means repeated deploys to the same configuration don't stack up unnecessary confirmation dialogs. You only see the modal when something would actually change. ![GitHub Actions deploy flow with branch selection and build configuration](/app-screenshots/feature-github-actions.jpg) ### The "Don't Show Again" Option For repositories you've vetted and trust, the dialog offers a "Don't show again for this repository" toggle. Once enabled, future pushes to that repo proceed without the modal — useful for CI repos where the workflow file is templated and predictable. ### Multi-Account Awareness If you manage multiple GitHub accounts, the pre-commit check now uses the same account you selected for the deploy. Previously, file lookups could fall back to your default account, which meant repos under a secondary login would fail the comparison or show the wrong diff. That's fixed — account context carries through the entire flow. ![Deploy history showing successful deployments with commit details](/app-screenshots/feature-deploy-history.jpg) ## Before vs After | Step | Before v1.24.2 | After v1.24.2 | |---|---|---| | Deploy pushes workflow file | Happens silently via GitHub API | Confirmation dialog shows exact files and branch | | Identical file already on GitHub | Still pushes (redundant commit) | Skipped automatically — no dialog, no commit | | Multiple GitHub accounts | File lookup uses default account | Uses the account you selected for this deploy | | Repeated deploys to same repo | Confirmation every time | "Don't show again" per repository | ## Try It Update to Server Compass v1.24.2 and trigger a GitHub Actions deploy. The confirmation dialog appears automatically — no configuration needed. You'll see every file before it's pushed, and you'll never wonder what just happened to your repository again. --- ## Per-app metrics on every Docker app — without standing up Grafana Source: https://servercompass.app/blog/per-app-metrics-dashboard Published: 2026-05-10 Tags: metrics, monitoring, p95, container-shell, system-tray, traefik, ssl v1.24.0 puts request rate, p50/p95/p99 latency, status-code distribution, CPU/memory traces, and a top-slow-paths panel on every Docker app — directly in Server Compass, no observability stack to maintain. Plus a one-click Container Shell and a system tray for live deployment status. Knowing whether an app on your VPS is healthy used to require a stack you didn't ship with the app. You'd add a Prometheus exporter, point a Prometheus at it, configure Grafana, build dashboards, run all of that in containers next to your actual workload — and then maintain the YAML when anything broke. The cost was high enough that you put it off, and then "is this thing slow?" became a guess. The other version of the same problem: an app crashes, or a deploy fails halfway through, and your only window into what's going on is `ssh user@host` followed by `docker ps`, then trying to remember the right `docker exec` syntax to get a shell inside the broken container. The fastest path to debugging a containerized app on your own server was a 30-second SSH ritual you wrote a hundred times. ## What changed In v1.24.0 every deployed Docker app gets its own **Metrics tab**: response times broken down by p50/p95/p99, requests stacked by status code, CPU/memory/network over time, and a top-slow-paths panel for HTTP apps routed through Traefik. No Prometheus, no Grafana, no exporter to install. The data is collected per-server, lazy-loaded per-tab, and you can switch the time range from 1 hour to 7 days. ![Per-App Metrics Dashboard with request volume, p95 latency, CPU and network charts in Server Compass](https://servercompass.app/app-screenshots/app_metrics_1.jpg) A new **Shell button** on the App detail opens a separate terminal window already inside the running container — no SSH, no `docker exec`, no remembering container IDs. And a **system tray icon** keeps a live list of pulling, building, and starting deployments visible while you do other things. ## How it works in practice ### Open the Metrics tab — it loads on demand Navigate to any deployed app. The Metrics tab sits next to the existing tabs and only fetches data when you actually open it, so the rest of the app pages stay fast. Once you're in, the time-range picker covers the last 1 hour, 6 hours, 12 hours, 24 hours, or 7 days. Pick a window and the charts re-bucket immediately. For any HTTP app routed through Traefik you get the full picture: - **p50, p95, p99 response times** — the latency breakdown you'd otherwise compute from raw access logs - **Stacked request charts** split by 2xx, 3xx, 4xx, and 5xx — so a sudden 5xx spike is visible at a glance - **Top slow paths** — a panel that ranks routes by latency, so you can spot which endpoints are dragging - **Universal CPU, memory, network in/out** — for every running container, regardless of routing ![Per-App Metrics Dashboard with status-code distribution, response percentiles, container health, and slow-path panel](https://servercompass.app/app-screenshots/app_metrics_2.jpg) For apps that publish a port directly (no Traefik domain), you still get the universal CPU/memory/network panels, plus a clear note explaining that HTTP request metrics need a Traefik domain to be measured. So you're never wondering whether the panel is broken or just inapplicable. ### Toggle collection per server, see exactly what it costs A switch in the Metrics tab turns collection on or off per server, with a confirmation. Below it, storage rows show how much disk metrics take up locally on your machine and on the VPS — so the answer to "how much will this grow?" is in the same screen, not in some hidden config. The data is yours. It lives on your VPS and your local machine, not in a third-party dashboard, and you can flip it off if a particular server doesn't need it. ### Drop into a container shell with one click The other big workflow shortcut: a **Shell button** on every App detail. Click it and a new terminal window opens, already inside the running container. Bash is used when available, with a graceful fallback to `sh` for minimal images. The terminal title shows the container name so you always know where you are. And if the container is so minimal that it has no shell at all (some scratch-based images), the terminal explains what's going on instead of dying silently. ![Shell button on the App detail opens a terminal window already inside the running container](https://servercompass.app/app-screenshots/container-shell.jpg) The SSH-and-docker-exec ritual stops being a thing you do. ### Watch deployments from the menu bar The new system tray icon (menu bar on macOS, system tray on Windows/Linux) lists deployments that are currently pulling, building, or starting — across all your servers — without you having to bring the Server Compass window forward. Favorite servers appear at the top, and a one-click **Show Window** brings the full UI back when the tray view isn't enough. Long deploys stop being something you context-switch to and become something you just... notice when they finish. ## Before vs After | Workflow | Before v1.24.0 | After v1.24.0 | |---|---|---| | Know p95 latency for an app | Install Prometheus + exporter + Grafana, build a dashboard, maintain it | Open the Metrics tab | | See whether 5xx errors spiked in the last hour | Tail Traefik logs, eyeball, count | Look at the stacked status-code chart, time range = 1h | | Find the slowest routes in an HTTP app | Parse access logs, group, sort | Top Slow Paths panel | | Get a shell inside a running container | SSH to the VPS → `docker ps` → `docker exec -it bash` (try `sh` if that fails) | Click `Shell` | | Tell whether anything is mid-deploy without bringing the window forward | Cmd-Tab into Server Compass and check | Glance at the tray | ## Also in v1.24.0 **Static site uploads stop dropping `dist`/`build`/`out`.** Static-site deploys no longer ship empty containers because the actual build output got silently excluded — those folders are now uploaded by default. **Generated `Dockerfile` and `docker-compose.yml` stay out of runtime images.** A small but real security improvement — Server Compass-generated build files are no longer shipped inside `/app` in the built image. **Domain Configurations now reads label-only Traefik stacks correctly.** If your compose files don't publish ports and route everything through Traefik labels (`traefik.enable=true` + shared external network), the Domain tab now shows the correct stack and container port instead of guessing wrong. Domain-to-stack matches are persisted, so refreshes and recheck no longer flip back to `Needs review`. And each domain page shows the exact labels you need (`traefik.enable=true`, network, router host, entrypoint, certresolver, loadbalancer port) for label-only setups. **SSL Certificate status syncs across screens.** A real Let's Encrypt cert now reflects on both the SSL Certificates list and the Domain Configurations list at once, instead of one saying `Active` and the other saying `No SSL`. Recheck a cert and the domain row updates immediately. ![Domain tab showing an active Let's Encrypt SSL certificate alongside a failed cert with a Restart Traefik & Retry action](https://servercompass.app/app-screenshots/ssl-recheck-active.jpg) ## Try it Update to v1.24.0 from the new sidebar update pill, open any deployed Docker app, and click the Metrics tab. Set the range to 24h. Look at the p95 line for the last day. If it's flat, you're done — that's the kind of answer Grafana would have charged you a weekend to surface. If it spiked, click into the Top Slow Paths panel and find which route caused it. Then hit the Shell button and look around. The instrumentation that used to be a project of its own is now just a tab. --- **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. If you work in AI-assisted coding, shared terminal sessions, or agent-driven shell workflows like the ones above, [1devtool](https://1devtool.com) is the StoicSoft network's tool for safer AI-assisted terminal work — shared sessions with auditing, preflight policy, and tiered model routing built in. --- ## Stop Exposing Internal Services to the Public Internet Source: https://servercompass.app/blog/connect-apps-private-network Published: 2026-05-02 Tags: app connections, private networking, docker network, network health, self-hosted, vps Link apps on the same VPS over a private network in a guided flow. No public ports for your databases, no manual Docker network surgery, no copy-pasted connection strings — just two clicks to connect your app to the services it depends on. You deploy a Next.js app to your VPS. It needs Redis. You deploy Redis as a separate app on the same box. Now you have to make them talk. If you've done this before, you know the choices. You can publish Redis on a public port, hope nobody finds it, and copy the public IP into your app's `REDIS_URL`. You can SSH in and hand-craft a Docker network, attach both containers, figure out the internal hostname, and pray the network survives the next redeploy. You can stand up a reverse proxy with auth in front of Redis, which is overkill for two containers that live three millimeters apart on the same disk. None of these are good. The first one is how databases end up on Have I Been Pwned. The second one breaks the moment you redeploy or restart Docker. The third one is more infrastructure to maintain than the thing it's protecting. ## What changed Now you can connect two apps on the same VPS through a guided flow. Pick the caller, pick the target, save. The two apps share a private Docker network the moment you confirm, and the producer can drop its public port if you want — its public surface goes from "open to the internet" to "open only to the apps you've linked." You get this from any app's detail page. Open the Connect Apps tab, pick the app you want to link to, and Server Compass does the network plumbing. ![Connected Apps tab in its empty state on an app's detail page, with the Connect App button waiting to be clicked](/app-screenshots/connect-apps-01-overview-connected-apps-empty-state.jpg) ## How it works in practice ### Pick the caller, pick the target — or let Auto-detect choose Say your Next.js frontend needs Redis. From the frontend's app page, you open Connect Apps and pick Redis as the target. If you're not sure which app is calling which, Auto-detect looks at the workloads and proposes the right direction. The frontend app gets connection values; Redis stays where it is. ### Get suggested env values for the services you actually use For common services — Redis, Postgres, MySQL, MongoDB — you don't have to type out a connection string. Server Compass suggests a working `REDIS_URL`, `DATABASE_URL`, or equivalent based on the target app's container name and the private network's internal hostname. You can edit the value before saving if you want a different env var name or a different format. That's the part that usually eats an afternoon: you remember Redis exists, you forget that the username is `default`, you forget that `rediss://` is for TLS and `redis://` isn't, you ship a 500 to production. Suggested values give you a reference that already works on your specific server. ![Connect Apps modal walking through Redis URL setup with REDIS_URL pre-populated and the private network selected](/app-screenshots/connect-apps-02-modal-setup-redis-url.jpg) ### Make service apps private by default When you finish linking, Server Compass offers to remove the producer app's public port. Your Redis container still listens on its internal port — your Next.js app still talks to it without a single change — but the public address is gone. Anyone scanning the internet for open Redis instances now sees nothing. This is the part that matters most. The way most public Redis incidents happen is not exotic: someone deploys Redis with a default config, exposes 6379, and forgets the requirepass line. With the public port removed, that whole class of mistake stops being possible. Your service apps become invisible to the public internet without you having to remember firewall rules, fail2ban configs, or reverse proxies. ![App detail page showing an active app-to-app connection through a shared private Docker network with the injected REDIS_URL env value](/app-screenshots/connect-apps-03-overview-active-connection.jpg) ### Manage links from the app view or the server view From an app's page you see the apps it's linked to. From the server's App Connections list you see every linked app pair on that VPS — useful when you have ten apps and need to remember which ones share a Postgres. Unlinking is a single click on either side, and it cleans up the network membership for you so you don't end up with stale Docker network references. ![Server-level App Connections list showing every linked app pair across the VPS in one view](/app-screenshots/connect-apps-04-server-app-connections-list.jpg) ### Spot broken networks before they page you The new Network Health view catches the failure modes that are easy to miss until production breaks. It shows you missing links — apps that think they're connected but aren't on the right network — broken memberships from a partial redeploy, and orphaned networks that nothing references anymore. Ghost networks are a rite of passage with hand-rolled Docker setups: every time you delete an app without cleaning up its network, you leave behind another `*_default` that nobody knows about. The health view lists them, and you remove them in one click. ![Network Health modal flagging a ghost network alongside healthy managed networks](/app-screenshots/connect-apps-05-network-health-modal.jpg) ## Before vs after | Step | Before | After | |---|---|---| | Make Redis reachable from your app | Publish 6379 publicly *or* hand-craft a Docker network | Click Connect Apps, pick Redis | | Get a working `REDIS_URL` | Look up your VPS public IP, remember the auth syntax, paste into env | Suggested value populated, edit if needed | | Stop exposing Redis to the internet | Manually edit firewall rules per server | One toggle when you connect | | Find out a connection broke | Wait for a 500 in production | Open Network Health, see the missing link | | Clean up an old app's network | SSH in, `docker network ls`, `docker network rm`, hope it isn't in use | Click "Clean up" in the health sheet | ## Who benefits most **Solo developers running a small stack on a single VPS.** You're the most likely to expose a database accidentally because you're moving fast and there's nobody else reviewing your firewall rules. App Connections makes private-by-default the path of least resistance. **Indie hackers running multiple side projects on one box.** Each project tends to grow its own little dependency graph — a marketing site that needs Postgres, an internal tool that needs Redis, a worker that needs both. The server-level App Connections list is how you remember what's wired to what when you come back to a project six months later. **Small teams running internal tools alongside production.** Your staging API, your internal admin panel, and your shared Postgres do not need public ports. They need to talk to each other. Now they can, without making the perimeter of your server bigger than it has to be. ## Try it Update to v1.22.0 and open any app on your VPS. The Connect Apps tab is on the app's detail page, and the Network Health view is one click away from there. If you've been putting off cleaning up the Docker networks on your server because of how tedious it usually is, this is the version where that gets easy. --- **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. --- ## Server Compass v1.21.0: Compose Drift Protection and Multi-Image Deploys Source: https://servercompass.app/blog/server-compass-v1-21-0-compose-drift-and-multi-image-deploy Published: 2026-04-24 Tags: changelog, release, compose, deployment, drift, env, logs, multi-image, ports, services, snapshots, version-history Adds safer Compose workflows with drift detection, baseline selection, and version history, plus faster one-or-many image deployment. It also improves multi-service editing and fixes compose, logs, and layout reliability issues. Server Compass v1.21.0 is now available with a strong focus on safer Compose operations and faster deployment flows for self-hosted apps. Adds safer Compose workflows with drift detection, baseline selection, and version history, plus faster one-or-many image deployment. It also improves multi-service editing and fixes compose, logs, and layout reliability issues. ## New Features - Deploy multiple images in one app setup — Pull Images now lets you add and configure several services before deployment; Configure service name, image tag, ports, and environment values for each service; Mix public and private images in one stack with linked GitHub login or saved registry credentials - Paste existing compose files — Paste your compose file, validate it instantly, then continue in the visual services editor; If the file needs source code to build, you get a clear prompt to switch to GitHub or Upload - Stop accidental overwrite on redeploy — If the server compose file was edited outside ServerCompass, redeploy now pauses and asks which version to keep - Choose your baseline version — From the Compose tab, compare differences and either import the live server version or push the ServerCompass version - Track and restore compose snapshots — Every save, import, and restore is recorded so you can preview, compare, and roll back quickly - Use native app menu shortcuts — Jump to Dashboard, server sections, [Command Palette](https://1devtool.com/features/command-palette), Migration Assistant, and Software Update from the desktop menu bar ## Improvements - Visual compose editing across more flows — The same Services & Images editor now works across Pull Images, pasted compose, advanced compose editing, and post-deploy compose edits - Clearer service editor status — Multi-service editing now shows better badges for build-only services, linked env values, and advanced fields - Smarter port suggestions — Suggested host ports auto-shift to available ports when conflicts are detected - Faster env save flow — Saving environment variables no longer forces a redeploy modal; apply changes when you are ready from the success banner ## Fixes - Fixed Overview logs staying empty for some Docker stacks — Per-service logs now load reliably even when apps are deployed outside the default folder layout - Fixed redeploy hiding compose drift behind generic errors — Drift now opens a dedicated resolution modal with a direct shortcut to the Compose tab - Fixed compose snapshot review feeling cramped — Snapshot preview now opens in a focused modal with clear compare and restore actions - Fixed multi-service editor layout glitches — Service tree, add-image controls, and details view now stay aligned while editing ## Why This Release Matters This release reduces risk during redeploys and speeds up day-to-day app operations. Teams get clearer Compose state transitions, better deployment ergonomics, and reliability fixes that make production changes less error-prone. Update to Server Compass v1.21.0 to get these improvements. --- **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. --- ## Cloudflare Tunnel Feels Random? A Reliability Checklist for Homelab Remote Access Source: https://servercompass.app/blog/cloudflare-tunnel-random-reliability-checklist Published: 2026-04-15 Tags: cloudflare, homelab, self-hosted, monitoring, domains, vps A practical checklist for intermittent Cloudflare Tunnel outages: system service setup, multiple connectors, log separation, external health checks, alerts, proxy headers, and fallback access. Cloudflare Tunnel is a strong fit for homelabs because you can expose services without opening inbound ports. The confusing part is reliability. When remote access drops, is the tunnel down, the connector unhealthy, the app container broken, DNS wrong, or the local network offline? The checklist below is designed to separate those failure domains quickly, then add enough monitoring that you find out before someone else reports the outage. ## Quick answer: why does Cloudflare Tunnel feel unreliable? Cloudflare Tunnel often feels random when all failures are grouped together. A `cloudflared` connector can be down while the app is healthy, the app can be down while the tunnel is healthy, or DNS and proxy headers can be wrong while both processes are running. Reliable homelab remote access comes from checking each layer separately. ## 1\. Run cloudflared as a real service Do not leave the connector running in an interactive shell. Install it as a system service with auto-restart, then verify it comes back after a reboot. ``` sudo systemctl status cloudflared sudo systemctl enable cloudflared sudo systemctl restart cloudflared journalctl -u cloudflared -n 100 --no-pager ``` In Server Compass, use the [SSH terminal](/features/ssh-terminal) for quick service checks and [download terminal logs](/features/download-terminal-logs) when you need to keep a record of the outage timeline. Also check whether the service is crash-looping after boot. A connector that restarts every few minutes can look like intermittent Cloudflare Tunnel downtime even when the dashboard briefly reports it as connected. ## 2\. Use two connectors for the same tunnel A single connector is a single point of failure. If your remote access matters, run a second connector on another machine, VM, or host on the same network. It does not need to be powerful; it only needs to survive when the primary connector host is rebooting or overloaded. After adding the second connector, test failure explicitly: stop the first connector and confirm the service still resolves through the second. Do this once during setup, not during an incident. ## 3\. Separate app, host, tunnel, and edge failures Most "tunnel is random" incidents are easier to debug when you check in layers: Layer Check Failure means App `curl localhost:3000/health` The app itself is unhealthy. Host CPU, RAM, disk, process status The machine cannot serve reliably. Connector `journalctl -u cloudflared` The tunnel agent is disconnected or restarting. Public URL Outside-in HTTPS check Users cannot reach the service. Server Compass gives you the host and app side in one place: container status, app logs, resource usage, activity logs, and open ports. ![Server Compass activity logs screen for server operation history](/app-screenshots/feature-activity-logs.jpg) ## 4\. Add external health checks and alerts Local checks tell you whether the app should work. External checks tell you whether it works for users. Add an outside-in HTTPS check for every remotely exposed service and alert after repeated failures. Use the [monitoring agent](/features/monitoring-agent), [alert rules](/features/alert-rules), and [notification channels](/features/notification-channels) in Server Compass for the host side, and deploy a small uptime checker such as Uptime Kuma if you want a dedicated public URL monitor on your own infrastructure. ![Server Compass monitoring agent screen for VPS health checks](/app-screenshots/feature-monitoring-agent.jpg) ## 5\. Configure proxy headers intentionally If your app sits behind Cloudflare, Traefik, Nginx, or another proxy layer, make sure it sees the correct visitor IP and scheme. Otherwise rate limits, audit logs, auth callbacks, and redirect logic can behave unpredictably. Server Compass includes [trust proxy header presets](/features/trust-proxy-headers) for providers including Cloudflare, plus [domain security settings](/features/domain-security) for headers, access controls, and HTTPS behavior. ![Server Compass trust proxy headers screen with Cloudflare proxy presets](/app-screenshots/feature-trust-proxy-headers.jpg) ## 6\. Keep a fallback path A tunnel is not a complete incident plan. Keep at least one fallback access path ready: - Provider console access for the VPS. - SSH key access that does not depend on the tunnel. - A documented local network path for homelab machines. - A known-good backup or snapshot if the host needs to be rebuilt. For VPS-hosted apps, [Server Compass server snapshots](/features/server-snapshots) give you a rebuild path if the host itself becomes the problem. ## Common mistakes - **No logs:** if you cannot compare app logs and connector logs, every outage looks random. - **One connector:** it works until the connector host reboots or hangs. - **No outside-in check:** local health does not prove public reachability. - **No fallback:** tunnel-only access makes tunnel incidents harder to fix. ## The starter checklist 1. Run `cloudflared` as a system service with auto-restart. 2. Add a second connector and test failover. 3. Check app, host, connector, and public URL separately. 4. Add resource and uptime alerts. 5. Configure trusted proxy headers and domain security. 6. Document a fallback access path. ## FAQ ### Why does cloudflared keep disconnecting? Common causes include a connector host rebooting, unstable local networking, DNS changes, system service misconfiguration, CPU or memory pressure, and a single connector with no failover. Start with `journalctl -u cloudflared` and compare it with app logs. ### Do I need two Cloudflare Tunnel connectors? For non-critical homelab services, one connector may be enough. For services you rely on remotely, two connectors remove the most obvious single point of failure. ### How should I monitor Cloudflare Tunnel services? Monitor the public URL from outside the network, the connector service status on the host, and the app container locally. Alert only after repeated failures so short network blips do not become noise. [Download Server Compass](https://servercompass.app) to monitor the VPS side of the tunnel, inspect logs, and harden the domains you expose. --- **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 and Dokploy 502 Bad Gateway Errors: Fast VPS Deployment Triage Source: https://servercompass.app/blog/coolify-dokploy-502-errors-triage Published: 2026-04-15 Tags: coolify, dokploy, troubleshooting, docker, deployment, vps A practical decision tree for Coolify 502 and Dokploy 502 Bad Gateway errors after Docker deploys: container health, bind address, internal port, proxy logs, startup grace, health endpoints, and rollback. A 502 after deploy usually means the reverse proxy cannot reach your app. The confusing part is that the container may still show as "running", which leads people to redeploy, rebuild, and change random settings before checking the actual upstream path. Whether you use Coolify, Dokploy, raw Docker Compose, or Server Compass, the fastest triage path is the same: process, bind address, port, proxy, startup timing, then rollback. ## Quick answer: what causes 502 after a Docker deploy? A 502 Bad Gateway after a self-hosted Docker deploy usually means Traefik, Nginx, or another reverse proxy cannot connect to the upstream app container. The most common causes are a crashed app process, wrong internal port, binding to `127.0.0.1` instead of `0.0.0.0`, missing environment variables, a slow startup, or a failed health check. ## 1\. Verify the container is healthy, not only running "Up" means Docker started the container. It does not mean your app is accepting traffic. First check logs and process state: ``` docker ps docker logs --tail=100 your-container docker inspect --format='{{json .State.Health}}' your-container ``` Look for boot errors, missing environment variables, failed migrations, port conflicts, or a server process that exited while the wrapper process stayed alive. In Server Compass, open [container status](/features/container-status) and [real-time logs](/features/container-logs) before you redeploy. The first useful clue is usually already there. ![Server Compass container status screen showing app health and uptime](/app-screenshots/feature-container-status.jpg) ## 2\. Confirm the app binds to the right address A common cause of 502s is an app that listens on `127.0.0.1` inside the container instead of `0.0.0.0`. The process is alive, but the proxy cannot reach it over the Docker network. Stack Common production bind setting Node/Express `app.listen(PORT, '0.0.0.0')` Next.js `next start -H 0.0.0.0` Vite preview `vite preview --host 0.0.0.0` FastAPI `uvicorn app:app --host 0.0.0.0` ## 3\. Match internal port, exposed port, and proxy target The proxy must send traffic to the port your app actually listens on inside the container. `EXPOSE` is documentation; it does not force your app to listen there. Check the app logs for a line like `Listening on port 3000`, then compare it to the service port and proxy target. In Server Compass, use [Port Management](/features/port-management) to inspect open ports and identify conflicts. ``` docker exec your-container sh -lc "ss -ltnp || netstat -ltnp" docker port your-container ``` ![Server Compass port management screen showing open ports and services](/app-screenshots/feature-ports.jpg) ## 4\. Read the reverse proxy error Reverse proxies are usually explicit about why they returned a 502. Look for errors like: - `connection refused`: app is not listening on the target port. - `no route to host`: network or container target is wrong. - `upstream timed out`: app is too slow or stuck during startup. - `bad gateway` after deploy only: new version failed health checks or boot. Server Compass records deployment output, build logs, activity logs, and container logs so you can correlate the proxy failure with what changed during deploy. Proxy error Most likely fix `connect: connection refused` Fix the app port, bind address, or startup command. `upstream timed out` Add a health check and increase startup grace. `host not found` Check Docker network and service names. ## 5\. Increase startup grace for slow boots Some apps need time to run migrations, warm caches, compile assets, or connect to a database. If the proxy routes traffic before the app is ready, users see 502 even though the app would have become healthy seconds later. Add a real health endpoint and give it time to pass before switching traffic. Server Compass supports [zero-downtime deployment](/features/zero-downtime), where health checks validate the new container before traffic moves. ## 6\. Re-test with a minimal endpoint When the app is complex, add one minimal route that does not touch the database: ``` app.get('/healthz', (_req, res) => { res.status(200).send('ok') }) ``` If `/healthz` works but the homepage 502s or times out, the proxy and port are probably correct. Move deeper into application startup, database connectivity, or upstream service calls. ## 7\. Roll back instead of debugging live forever If production is down and the previous deployment worked, restore service first. Then debug the failed build with logs and a staging environment. ![Server Compass rollback screen for restoring a previous deployment](/app-screenshots/feature-rollback.jpg) Server Compass keeps [deployment history](/features/deployment-history) and supports [one-click rollback](/features/rollback), which gives you a clean escape hatch when a bad deployment causes a 502. ## 502 decision tree 1. Does the container log show a startup error? 2. Is the app listening on `0.0.0.0`? 3. Does the proxy target the actual internal port? 4. Do proxy logs say refused, timeout, or no route? 5. Does a minimal health endpoint work? 6. Can you roll back to restore production while debugging? ## FAQ ### Why do I get 502 if the container is running? Docker can report a container as running even when the app process inside it is not ready, is listening on the wrong address, or is serving on a different port than the proxy expects. ### Is Coolify or Dokploy causing the 502? Sometimes the platform configuration is wrong, but most 502s come from the app, port, bind address, Docker network, environment variables, or proxy target. Check those before reinstalling the platform. ### How do I prevent 502s on future deploys? Add a real health endpoint, configure the correct internal port, bind to `0.0.0.0`, keep startup logs visible, and use rollback or zero-downtime deployment so a bad version does not replace a working one. [Download Server Compass](https://servercompass.app) to keep logs, ports, health status, deploy history, and rollback in one workflow instead of chasing 502s through five terminals. --- **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. --- ## Migration Plan From Vercel, Railway, or Render to a Self-Hosted VPS Source: https://servercompass.app/blog/managed-platform-to-self-hosted-vps-migration-plan Published: 2026-04-15 Tags: migration, self-hosted, vps-deploy, deployment, backups, dns A rollback-first migration runbook for moving from Vercel, Railway, Render, Heroku, or another managed platform to your own VPS with config parity, staging rehearsal, backups, DNS cutover, monitoring, and a 24-hour rollback window. Moving from a managed platform to a VPS is usually driven by cost, control, or both. The risk is not Docker. The risk is an unplanned cutover: missing environment variables, DNS cache delays, database drift, broken background jobs, and no clear way back. A no-regret migration is rollback-first. You rehearse the new environment, keep the old platform warm, cut DNS with low TTL, and only remove the old system after the new one has survived real traffic. ## Quick answer: how do you migrate with less downtime? To migrate from Vercel, Railway, Render, Heroku, or another managed platform to a VPS, replicate environment variables first, rehearse the app on a staging domain, back up the database and uploaded files, lower DNS TTL before cutover, switch traffic during a rollback window, and keep the old platform running for at least 24 hours. ## 1\. Freeze writes long enough to inventory reality Before moving anything, write down the current production shape: - App repository, branch, build command, and start command. - Environment variables and secrets. - Database type, version, extensions, and connection string. - Background workers, queues, cron jobs, and scheduled tasks. - Domains, redirects, SSL behavior, and proxy headers. - External integrations such as storage, email, payments, and webhooks. If the source is another server management platform, use the [Server Compass migration wizard](/features/migration-wizard) to discover existing apps and import what can be automated. If the source is a hosted app platform such as Vercel, Railway, Render, Netlify, or Heroku, the same inventory still matters. Export the behavior, not just the code repository. ![Server Compass migration providers screen for selecting a source platform](/app-screenshots/feature-migration-providers.jpg) ## 2\. Replicate config before deploying code Most failed migrations come from config drift. Do not wait until cutover to discover that a secret is missing or a callback URL still points at the old host. Store production variables in the [Server Compass .env Vault](/features/env-vault), import them into the new app, then explicitly change only the values that should differ: database host, staging domain, debug flags, and provider credentials. ![Server Compass encrypted environment variable vault](/app-screenshots/feature-env-vault.jpg) ## 3\. Rehearse in staging with production-like data Deploy the app to the VPS under a staging domain before touching production DNS. Run smoke tests against the same paths users depend on: - Login and session handling. - Database reads and writes. - File uploads and downloads. - Email, webhooks, and background jobs. - Payment or auth provider callbacks. - Admin-only workflows. Use [staging or preview environments](/features/preview-environments) and [activity logs](/features/activity-logs) to make each rehearsal repeatable. If the runbook only works once because someone clicked around manually, it is not ready. ## 4\. Take backups before the cutover A migration without a backup is a bet. Before the DNS change, capture: - A database dump from the old platform. - A copy of uploaded files or object storage state. - The new VPS app configuration. - Server-level snapshots if the VPS already has multiple services. Server Compass supports [encrypted backups](/features/server-backups) and [server snapshots](/features/server-snapshots) so you can keep a restorable copy before and after migration. ## 5\. Lower TTL before DNS cutover Lower DNS TTL at least several hours before cutover, preferably the day before. Then verify the new VPS domain and SSL path before switching the production record. ![Server Compass DNS verification screen for checking domain records before cutover](/app-screenshots/feature-dns-verify.jpg) Server Compass [DNS verification](/features/dns-verification), [automatic SSL](/features/auto-ssl), and [certificate viewer](/features/certificate-viewer) help catch the boring domain mistakes that cause avoidable downtime. ## 6\. Cut over with a rollback window During the cutover window: 1. Pause writes or put the app into maintenance mode if data consistency requires it. 2. Run the final database dump or sync. 3. Restore/import data on the VPS. 4. Run smoke tests against the new app. 5. Update DNS to point production traffic at the VPS. 6. Watch logs, resources, and external health checks. Keep the old platform warm for at least 24 hours. Do not delete the previous deployment, database, or environment variables immediately after the first successful request. For high-write applications, use a shorter maintenance window and make the old platform read-only before the final sync. For low-write apps, a final dump and restore may be enough. The key is choosing the data strategy before users can write to both systems. ## 7\. Know exactly how to roll back The rollback plan should fit on one screen: Failure Rollback action App fails boot or returns 502 Restore old DNS target and investigate VPS logs. Database import is wrong Keep old platform read/write, restore dump to a fresh VPS database. New deploy is bad Use deployment history or rollback to the previous VPS version. VPS host issue Rebuild from snapshot or keep traffic on old platform. ![Server Compass rollback screen for restoring previous deployments](/app-screenshots/feature-rollback.jpg) ## 8\. After 24 hours, clean up deliberately Once the VPS has handled real traffic, review metrics, logs, backups, and error rates. Then update documentation, raise DNS TTL, remove temporary staging secrets, and decide when to retire the old platform. Add ongoing [alert rules](/features/alert-rules), [resource monitoring](/features/resource-monitoring), and scheduled backups before you declare the migration finished. ## The migration runbook - Inventory production behavior and dependencies. - Replicate environment variables and secrets first. - Rehearse in staging with real smoke tests. - Back up data and server configuration. - Lower TTL before cutover. - Keep rollback warm for 24 hours. - Only then remove the old platform. ## FAQ ### Can I migrate from Vercel to a VPS? Yes, especially for apps that can run as a Docker container or Node.js service. The main work is replacing managed assumptions: environment variables, build settings, domains, SSL, background jobs, storage, and deployment automation. ### How do I migrate the database? Take a fresh dump from the old database, restore it to the VPS or new database host, run smoke tests, then freeze writes or run a final sync during cutover. Keep the old database available until the VPS has handled real traffic. ### How much downtime should I expect? With a rehearsed cutover and low DNS TTL, small apps can often keep downtime to minutes. Apps with heavy writes or large databases need more planning because data consistency, not DNS, becomes the hard part. [Download Server Compass](https://servercompass.app) to import existing apps, manage config, verify domains, monitor the cutover, and keep rollback available while the migration settles. --- **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. --- ## Postgres "Invalid Checkpoint Record" in Docker: Prevention-First Playbook Source: https://servercompass.app/blog/postgres-invalid-checkpoint-self-hosted-deployments Published: 2026-04-15 Tags: postgres, database, self-hosted, docker, backups, vps Prevent PostgreSQL invalid checkpoint record failures in Docker and VPS deployments with reliable PGDATA storage, graceful shutdowns, health checks, daily backups, and weekly restore drills. PostgreSQL "invalid checkpoint record" errors are the kind of failure that turn a quiet VPS into a stressful recovery session. They usually appear after an unclean shutdown, storage problem, forced container kill, or restore attempt that was never tested before production needed it. The right posture is prevention-first. You want Postgres on reliable storage, with graceful shutdown behavior, boring backups, and a restore drill that proves the backups work. ## Quick answer: how do you prevent invalid checkpoint errors? Keep `PGDATA` on reliable local storage, give the Postgres container enough time to shut down, add a health check, pin the PostgreSQL major version, run daily `pg_dump` backups, and test restores to a fresh instance every week. Those steps reduce the main causes behind Docker Postgres corruption, missing WAL records, and "invalid checkpoint record" recovery panic. ## 1\. Put PGDATA on reliable local storage PostgreSQL is sensitive to storage guarantees. For a small self-hosted deployment, the safest default is boring local block storage from a reputable VPS provider. Avoid placing `PGDATA` on unstable network mounts, sync folders, or experimental filesystems. This is especially important for Docker Compose Postgres deployments, where the named volume is the database. A simple Compose baseline should keep the data directory in a named volume or a dedicated host path that you can back up consistently: ``` services: postgres: image: postgres:16 restart: unless-stopped stop_grace_period: 60s environment: POSTGRES_DB: app POSTGRES_USER: app POSTGRES_PASSWORD: change-me volumes: - postgres-data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U app -d app"] interval: 10s timeout: 5s retries: 5 volumes: postgres-data: ``` Server Compass includes a [Docker Compose editor](/features/docker-compose-editor) so you can keep this configuration visible instead of buried in a remote file you only edit during emergencies. ## 2\. Give Postgres time to shut down Databases should not be killed like stateless workers. Set a real `stop_grace_period`, avoid aggressive restart loops, and do not run routine maintenance by force-removing containers. If the host is low on memory or disk, fix the host problem before restarting repeatedly. Server Compass helps here with [container health monitoring](/features/container-status), [live logs](/features/container-logs), and [resource monitoring](/features/resource-monitoring). Before you restart a database container, check whether the server is already out of memory or disk. ![Server Compass container status screen showing health and resource usage](/app-screenshots/feature-container-status.jpg) ## 3\. Schedule daily dumps and send them offsite A volume snapshot is useful, but a logical dump is still the easiest recovery artifact to understand and test. For most small apps, schedule a daily `pg_dump` and upload it to offsite storage. ``` pg_dump \\ --format=custom \\ --no-owner \\ --no-acl \\ --file=/backups/app-$(date +%F).dump \\ "$DATABASE_URL" ``` Use [Server Compass backups](/features/server-backups) for encrypted scheduled backup jobs and S3-compatible storage. If the database belongs to a larger app stack, pair database dumps with [server snapshots](/features/server-snapshots) so you can rebuild the app, domains, cron jobs, and environment variables together. ## 4\. Test restore weekly to a fresh instance "Backup exists" and "restore works" are different statements. Once a week, restore the latest dump into a fresh Postgres container, run a count query against important tables, and verify the app can start against the restored database. ``` createdb app_restore pg_restore --dbname=app_restore --clean --if-exists /backups/latest.dump psql app_restore -c "select count(*) from users;" ``` The [database admin interface](/features/db-admin), [SQL editor](/features/sql-editor), and [tables browser](/features/tables-browser) make the smoke test faster: open the restored database, confirm schema visibility, and inspect a few critical tables without memorizing recovery commands. ![Server Compass database admin interface for browsing and querying self-hosted databases](/app-screenshots/feature-db-admin.jpg) ## 5\. Pin major versions and upgrade intentionally Do not deploy `postgres:latest` for production data. Pin the major version, read upgrade notes, and treat major upgrades as migrations with backups and rollback plans. Risk Safer default `postgres:latest` `postgres:16` or another intentional major version Network-mounted `PGDATA` Local block storage with tested backups Manual backup only Scheduled dump plus offsite encrypted copy Untested restore Weekly restore drill to a fresh instance ## If the error already happened Stop making changes first. Preserve the data directory, copy logs, and identify the most recent known-good backup before trying destructive repair commands. If production is down, restore to a fresh instance and point the app there only after the smoke test passes. Avoid treating commands like `pg_resetwal` as the normal recovery path. They can sometimes help an expert extract data from a damaged cluster, but they are not a substitute for a tested backup and may make data loss permanent if used blindly. Use [activity logs](/features/activity-logs) to review what happened before the failure, then write down the timeline. The goal is not only to recover. It is to remove the condition that caused the database to be killed or stored unsafely. ## The no-panic checklist - Postgres data lives on reliable local storage. - The container has a health check and a real shutdown grace period. - Backups run daily and leave the server. - Restores are tested weekly to a clean instance. - Major versions are pinned and upgraded deliberately. ## FAQ ### What does PostgreSQL invalid checkpoint record mean? It usually means PostgreSQL cannot find a valid checkpoint in the write-ahead log during startup or recovery. Common causes include unclean shutdowns, unsafe storage, interrupted writes, damaged volumes, and incomplete restore procedures. ### How do I back up Postgres running in Docker? Use logical dumps with `pg_dump` for regular backups, store them offsite, and test `pg_restore` into a fresh container. Volume snapshots can help, but a tested logical dump is easier to validate and migrate. ### How often should I test Postgres restores? Weekly is a strong default for small production apps. At minimum, test a restore after every major schema change, PostgreSQL upgrade, or infrastructure migration. [Download Server Compass](https://servercompass.app) to manage the stack, schedule encrypted backups, and keep database recovery from becoming guesswork. --- **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. --- ## Why Self-Hosted VPS Setups Break at 2 AM and How to Catch Issues First Source: https://servercompass.app/blog/why-self-hosted-setups-break-at-2am Published: 2026-04-15 Tags: self-hosted, monitoring, vps, docker, homelab, best-practices A practical 15-minute self-hosted monitoring baseline for VPS apps: uptime checks, Docker alerts, CPU/RAM/disk thresholds, SSL expiry checks, notifications, and incident drills. The most painful self-hosting outage is not the one where a container crashes. It is the one where a container crashes, the SSL certificate expires, or the disk fills up, and the first signal comes from a user asking why the app is down. That pattern shows up constantly in self-hosting and homelab discussions: people move from managed platforms to a VPS, gain control and lower costs, then realize they also lost the built-in alerts that used to tell them when something was unhealthy. The fix is not a giant observability stack on day one. Start with a small baseline that catches the failures users actually notice. ## Quick answer: what should you monitor first? For most self-hosted VPS apps, the first monitoring layer should cover public uptime, Docker container health, CPU, memory, disk usage, SSL certificate expiry, and deployment failure notifications. That gives you early warning for the outages users feel first: expired HTTPS, 502 errors, full disks, crashed containers, and database connection failures. ## 1\. List the services that matter Do not begin with every metric your server can produce. Begin with what must be true for your product to work: - The public app URL returns a healthy response. - The reverse proxy can route traffic to the app container. - The database accepts connections. - The disk has enough free space for logs, builds, and database writes. - The SSL certificate is valid and not close to expiry. In Server Compass, keep these services visible from the app dashboard and container status views. The point is to make the current state obvious before you open a terminal. ## 2\. Add outside-in uptime checks A container can be running while the app is still unreachable. That is why every production app needs at least one outside-in check against the public URL. Use a lightweight `/health` endpoint if your app has one, or a simple page that exercises the app and database path. A useful first baseline: - Check the production URL every 60 seconds. - Alert after 2 or 3 consecutive failures, not after one noisy blip. - Track response code and response time. - Run the check from outside the VPS network. Server Compass can also deploy templates like Uptime Kuma when you want a dedicated self-hosted uptime checker alongside the built-in status and alerting tools. That gives you both a VPS monitoring dashboard and an outside-in website uptime monitor. ## 3\. Watch host and container resources The classic 2 AM failure is usually boring: memory pressure, a runaway log file, a full disk, or a container that restarted until the app entered a bad state. Add host-level and container-level thresholds before chasing advanced metrics. ![Server Compass resource monitoring screen with CPU, memory, and disk graphs](/app-screenshots/feature-resource-monitor.jpg) Use the [Server Compass monitoring agent](/features/monitoring-agent) to track CPU, RAM, disk, and container usage continuously. Then create [alert rules](/features/alert-rules) for the thresholds you would act on: Signal Starter threshold Why it matters Disk usage 80% warning, 90% critical Databases and Docker builds fail badly when disk runs out. Memory usage 85% for 10 minutes Sustained pressure often comes before OOM kills. Container restarts Any unexpected restart A running container is not always a stable container. CPU usage 90% for 15 minutes Useful for runaway jobs, crawlers, and inefficient deploys. ## 4\. Treat SSL expiry as an outage An expired certificate looks like a hard outage to most users. Add SSL checks to the same alert path as uptime and disk. The check should warn early enough that you can fix DNS, proxy, or ACME renewal issues during normal hours. ![Server Compass certificate viewer showing SSL issuer and expiry details](/app-screenshots/feature-cert-viewer.jpg) Server Compass shows certificate details from the domain panel, including issuer and expiry data. Pair the [certificate viewer](/features/certificate-viewer) with [DNS verification](/features/dns-verification) so you can confirm that the domain is pointed correctly before renewal problems turn into support tickets. ## 5\. Route alerts somewhere you will actually see Alerts are only useful if they land where you respond. For solo developers, that might be Telegram, Discord, email, or a webhook into a team chat. For teams, use severity levels: - **Critical:** public app down, database unreachable, disk above 90%. - **Warning:** disk above 80%, SSL expires soon, memory pressure. - **Info:** successful deploys, scheduled backups, maintenance tasks. ![Server Compass notification channels screen for alert delivery](/app-screenshots/feature-notifications.jpg) Configure [notification channels](/features/notification-channels) in Server Compass and send a test alert before relying on them. A broken notification channel is just another silent failure. ## 6\. Run one monthly incident drill Monitoring is not done when the dashboard is green. Once a month, run a small drill: 1. Trigger a test alert and confirm delivery. 2. Restart one non-critical container and verify the expected status change. 3. Check one backup and confirm it can be restored or inspected. 4. Review SSL expiry dates for production domains. 5. Open recent activity logs and confirm destructive operations are auditable. The drill takes less than 20 minutes, but it catches the exact configuration drift that makes real incidents painful. ## Common mistakes - **Monitoring too much first:** start with availability, disk, memory, SSL, and restarts. - **No severity levels:** every alert cannot be urgent or you will ignore all of them. - **No restore test:** a backup that has never been restored is only a hope. - **Only checking the server:** outside-in checks catch proxy, DNS, and certificate failures. ## The 15-minute baseline Install the monitoring agent, add alert rules for disk/RAM/container restarts, verify SSL expiry, route alerts to a channel you watch, and run one test notification. That baseline will not replace a full observability stack, but it will stop users from becoming your monitoring system. ## FAQ ### What should I monitor on a self-hosted VPS? Monitor public uptime, Docker container status, CPU, memory, disk usage, SSL certificate expiry, deployment failures, and database reachability. Add deeper application metrics only after those basics are reliable. ### Do I need Prometheus and Grafana for one VPS? Not immediately. Prometheus and Grafana are useful when you need historical dashboards and custom metrics, but a small VPS can start with uptime checks, resource alerts, log access, and notification channels. ### How do I get Docker container alerts? Alert on unexpected restarts, unhealthy containers, high memory usage, and disk pressure. Server Compass surfaces container health and resource usage without requiring you to SSH into the VPS and inspect `docker ps` manually. [Download Server Compass](https://servercompass.app) and set up the monitoring baseline before the next 2 AM surprise. --- **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. --- ## 20 Best Self-Hosted Apps You Can Run on a VPS Source: https://servercompass.app/blog/best-self-hosted-apps-vps Published: 2026-04-05 Tags: self-hosted, templates, docker, deployment, homelab The definitive self-hosted software list for 2026. From n8n and Plausible Analytics to Supabase and Nextcloud, here are 20 apps worth running on your own server with one-click deploys. Every year the list of awesome self-hosted software grows longer, and every year more developers decide to stop renting their tools from SaaS companies. The appeal is straightforward: you own your data, you pay a flat monthly VPS cost instead of per-seat pricing, and you can customize everything. But with thousands of open-source projects out there, knowing which ones are actually worth self-hosting can be overwhelming. This is our curated list of the 20 best self-hosted apps you can run on a VPS in 2026, organized by category. Every app on this list has a [one-click deploy template](/templates) in Server Compass, so you can go from zero to running in under a minute. ## Automation & Workflows ### 1\. n8n — Workflow Automation [n8n](/templates/n8n) is a self-hosted alternative to Zapier and Make that lets you connect APIs, databases, and services into automated workflows using a visual editor. It supports 400+ integrations and lets you write custom JavaScript or Python when the built-in nodes aren't enough. Self-hosting n8n means unlimited workflows and executions with no per-task pricing. ### 2\. Home Assistant — Home Automation [Home Assistant](/templates/home-assistant) is the gold standard for smart home automation with over 2,000 integrations. It connects to Zigbee, Z-Wave, Wi-Fi, and Bluetooth devices, and lets you build automations that run entirely on your own hardware. Running it on a VPS gives you remote access to your home dashboard without exposing your local network. ## Analytics & Monitoring ### 3\. Plausible Analytics — Privacy-Friendly Web Analytics [Plausible](/templates/plausible) is a lightweight, privacy-focused alternative to Google Analytics. It gives you page views, referrers, and device stats in a clean dashboard without cookies or personal data collection. The self-hosted version is completely free and keeps all your traffic data on your own server. ### 4\. Umami — Minimal Analytics [Umami](/templates/umami) is even more minimal than Plausible. It tracks page views, referrers, and custom events with a script under 2 KB. If you want simple analytics without the bloat, Umami is the lightest option that still gives you actionable data. ### 5\. Uptime Kuma — Uptime Monitoring [Uptime Kuma](/templates/uptime-kuma) monitors your websites, APIs, and services and sends alerts when something goes down. It supports HTTP, TCP, DNS, Docker, and Steam Game monitors, with notifications via Slack, Discord, Telegram, email, and 90+ other services. Think of it as a self-hosted Uptime Robot. ### 6\. Grafana — Dashboards & Visualization [Grafana](/templates/grafana) is the industry-standard platform for building monitoring dashboards. Connect it to Prometheus, InfluxDB, PostgreSQL, or dozens of other data sources and build real-time visualizations for server metrics, application performance, or business KPIs. Pair it with [Prometheus](/templates/prometheus) for a complete monitoring stack. ## Databases & Backend ### 7\. Supabase — Firebase Alternative [Supabase](/templates/supabase) gives you a full backend-as-a-service stack: PostgreSQL database, authentication, real-time subscriptions, edge functions, and a Studio dashboard. Self-hosting means no row limits, no bandwidth caps, and no monthly bills that scale with your user count. It is the most popular open-source Firebase alternative for a reason. ### 8\. Appwrite — Backend-as-a-Service [Appwrite](/templates/appwrite) is another strong BaaS option with user auth, databases, file storage, cloud functions, and real-time messaging. It has SDKs for Flutter, React Native, Swift, Android, and web frameworks. If you prefer a more opinionated backend with built-in multiplatform SDKs, Appwrite is worth trying alongside Supabase. ### 9\. NocoDB — Airtable Alternative [NocoDB](/templates/nocodb) turns any SQL database into a smart spreadsheet with forms, kanban views, galleries, and a REST API. Connect it to your existing PostgreSQL or MySQL database and give non-technical team members a visual interface without paying for Airtable seats. Deploy it with a [single click](/blog/no-code-templates-one-click-deploy). ## File Storage & Documents ### 10\. Nextcloud — Cloud Storage & Collaboration [Nextcloud](/templates/nextcloud) is the self-hosted replacement for Google Drive, Dropbox, and Google Docs combined. It handles file sync, calendars, contacts, video calls, and collaborative document editing. With the app store you can extend it with hundreds of plugins. Self-hosting gives you unlimited storage limited only by your VPS disk size. ### 11\. Immich — Photo & Video Backup [Immich](/templates/immich) is a Google Photos replacement with mobile auto-upload, face recognition, location mapping, and shared albums. It has native iOS and Android apps that feel polished enough to replace the real thing. If you care about keeping your photos private and off Big Tech servers, Immich is the clear choice. ### 12\. Paperless-ngx — Document Management [Paperless-ngx](/templates/paperless-ngx) scans, OCRs, tags, and indexes your documents so you can search them instantly. Upload a PDF or photo of a receipt and it automatically extracts the text, suggests tags, and files it away. Going paperless has never been this easy to self-host. ## Publishing & Communication ### 13\. Ghost — Publishing Platform [Ghost](/templates/ghost) is a modern publishing platform for blogs, newsletters, and paid memberships. It includes a beautiful editor, built-in SEO, newsletter delivery, and Stripe integration for subscriptions. Self-hosting Ghost saves you the $31+/month Ghost Pro fee and lets you customize the theme and functionality completely. ### 14\. Listmonk — Newsletter & Email Marketing [Listmonk](/templates/listmonk) is a high-performance, self-hosted newsletter manager. It handles subscriber lists, campaign delivery, analytics, and template management. Connect it to any SMTP provider and send millions of emails without per-subscriber pricing from Mailchimp or ConvertKit. ## Development Tools ### 15\. Gitea — Self-Hosted Git [Gitea](/templates/gitea) is a lightweight GitHub alternative written in Go. It gives you Git hosting, pull requests, issues, CI/CD (via Gitea Actions), container registry, and package management. It runs on minimal resources and is perfect for teams that want their code on their own infrastructure. ### 16\. Meilisearch — Search Engine [Meilisearch](/templates/meilisearch) is a lightning-fast, typo-tolerant search engine with a simple REST API. Add full-text search to your app in minutes. It supports filtering, faceting, and geo-search out of the box. Self-hosting means no search-as-a-service fees and sub-50ms response times on modest hardware. ## Infrastructure ### 17\. Vaultwarden — Password Manager [Vaultwarden](/templates/vaultwarden) is a lightweight, Bitwarden-compatible password manager server. It works with all official Bitwarden clients (browser extensions, mobile apps, desktop apps) but uses a fraction of the resources. Self-hosting your passwords means they never leave your server, and you get premium Bitwarden features for free. ### 18\. MinIO — S3-Compatible Object Storage [MinIO](/templates/minio) gives you Amazon S3-compatible object storage on your own server. Use it as a backup target, media storage, or the file backend for apps like Supabase or Nextcloud. Any tool that speaks S3 can talk to MinIO, making it the most versatile self-hosted storage solution. ### 19\. Portainer — Container Management [Portainer](/templates/portainer) is a web UI for managing Docker containers, images, volumes, and networks. If you prefer a visual interface for container operations, Portainer gives you a dashboard to inspect logs, restart containers, and manage stacks without touching the terminal. ## Media ### 20\. Jellyfin — Media Streaming Server [Jellyfin](/templates/jellyfin) is a free, open-source media server for movies, TV shows, music, and live TV. It transcodes on the fly, supports multiple user accounts, and has apps for Roku, Apple TV, Android TV, Fire TV, and mobile devices. Unlike Plex, Jellyfin has no premium tier and no phone-home requirements. ## Quick Comparison Table App Category Replaces Min RAM n8n Automation Zapier, Make 512 MB Home Assistant Automation SmartThings 1 GB Plausible Analytics Google Analytics 512 MB Umami Analytics Google Analytics 256 MB Uptime Kuma Monitoring Uptime Robot 256 MB Grafana Monitoring Datadog, New Relic 256 MB Supabase BaaS Firebase 4 GB Appwrite BaaS Firebase 2 GB NocoDB No-Code Airtable 256 MB Nextcloud Storage Google Drive, Dropbox 1 GB Immich Photos Google Photos 4 GB Paperless-ngx Documents Evernote Scannable 1 GB Ghost Publishing WordPress, Substack 512 MB Listmonk Email Mailchimp, ConvertKit 256 MB Gitea Dev Tools GitHub, GitLab 256 MB Meilisearch Search Algolia 256 MB Vaultwarden Security 1Password, Bitwarden 128 MB MinIO Storage Amazon S3 256 MB Portainer Containers Docker CLI 256 MB Jellyfin Media Plex, Netflix 1 GB ## How to Deploy Any of These Apps You can install each of these the traditional way: SSH into your server, write a `docker-compose.yml`, configure environment variables, set up a reverse proxy, and request SSL certificates. That works, but it takes time and is easy to get wrong. With [Server Compass](https://servercompass.app), every app on this list has a [one-click deploy template](/features/template-deployment). You pick the app from the [template gallery](/templates), click Deploy, and Server Compass handles the Docker Compose file, environment variables, port mappings, reverse proxy configuration, and SSL certificates automatically. No terminal required. Here is what the workflow looks like: 1. Connect your VPS to Server Compass (any provider: Hetzner, DigitalOcean, Linode, Vultr, or your own hardware). 2. Open the [Stack Wizard](/features/docker-stack-wizard) and search for the app you want. 3. Click Deploy. Server Compass generates the Docker Compose stack, configures persistent volumes, and sets up Traefik for automatic HTTPS. 4. Point your domain. Server Compass provisions a Let's Encrypt certificate within seconds. That is it. No YAML editing, no SSH sessions, no debugging port conflicts. ## Choosing the Right VPS for Self-Hosting Most of the apps on this list run comfortably on a $5-10/month VPS. A server with 2 GB RAM and 40 GB SSD can handle 5-8 lightweight apps (Uptime Kuma, Umami, Vaultwarden, Gitea, Listmonk, NocoDB, Meilisearch, and MinIO all fit). For heavier apps like Supabase, Immich, or Nextcloud, step up to 4 GB RAM. The math almost always works out in your favor. A typical SaaS stack of analytics + email marketing + password management + [project management](https://1devtool.com/features/multi-account-git) could cost $50-100/month in subscriptions. The same tools self-hosted on a $10 VPS cost you just that $10. ## Start Building Your Self-Hosted Stack The best self-hosted apps are the ones you actually use. Start with one or two that solve an immediate problem — maybe [Uptime Kuma](/templates/uptime-kuma) to monitor your sites, or [Plausible](/templates/plausible) to replace Google Analytics. Once you see how easy it is, you will keep adding more. Server Compass ships with [247+ one-click templates](/blog/50-one-click-deploy-templates-self-hosted) covering all 20 apps on this list and hundreds more. Browse the full [template gallery](/templates) or [download Server Compass](https://servercompass.app) to start deploying. --- **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 Self-Hosted PaaS Platforms in 2026: Coolify, CapRover, Dokploy, and Server Compass Compared Source: https://servercompass.app/blog/best-self-hosted-paas-platforms-2026 Published: 2026-04-05 Tags: self-hosted, comparison, coolify, deployment, docker, vercel-alternative Compare the best self-hosted PaaS platforms in 2026. An in-depth look at Coolify, CapRover, Dokploy, and Server Compass covering features, pricing, templates, and ease of use to help you pick the right open-source PaaS for your VPS. Running your own self-hosted PaaS has become one of the smartest moves a developer or team can make in 2026. Cloud PaaS providers like Vercel, Railway, and Render keep raising prices, adding per-seat fees, and charging for bandwidth that used to be free. The open-source PaaS ecosystem has responded with tools that give you the same push-to-deploy experience on a $6/month VPS. But which self-hosted PaaS should you actually use? In this guide, we compare four of the most popular options — **Coolify**, **CapRover**, **Dokploy**, and **Server Compass** — across the dimensions that matter: features, ease of setup, template libraries, pricing, and day-to-day developer experience. If you've been searching for a [Vercel alternative you can self-host](/compare/vercel), this comparison will help you decide. ## What Is a Self-Hosted PaaS? A Platform as a Service (PaaS) abstracts away the infrastructure layer so you can focus on deploying and running applications. Traditional PaaS platforms like Heroku, Vercel, and Railway host everything for you — but charge accordingly. A **self-hosted PaaS** gives you the same convenience — git-push deployments, automatic SSL, container orchestration, reverse proxies — but runs on infrastructure you own. You bring a VPS (from Hetzner, DigitalOcean, Linode, or any provider), install the platform, and deploy apps just like you would on Vercel. The difference is that you pay for the VPS and nothing else. No per-seat charges, no bandwidth bills, no build-minute limits. If you're new to the idea, [our guide on why self-hosting saves developers money](/blog/why-self-hosting-is-the-smartest-move-for-developers) covers the cost math in detail. ## The Four Platforms at a Glance Feature Coolify CapRover Dokploy Server Compass Type Web-based (self-hosted) Web-based (self-hosted) Web-based (self-hosted) Desktop app (Mac, Windows, Linux) License Open source (Apache 2.0) Open source (Apache 2.0) Open source (Apache 2.0 with caveats) Proprietary (one-time purchase) Pricing Free self-hosted / $5/mo cloud Free Free $29 one-time Templates ~30 one-click services ~50 one-click apps ~20 templates 247+ one-click templates Docker support Docker Compose, Dockerfiles Dockerfiles, captain-definition Docker Compose, Dockerfiles Docker Compose, Dockerfiles, registries Reverse proxy Traefik (built-in) Nginx (built-in) Traefik (built-in) Traefik + Nginx/Caddy support SSL certificates Auto (Let's Encrypt) Auto (Let's Encrypt) Auto (Let's Encrypt) Auto (Let's Encrypt) Database management Basic (deploy only) None built-in Basic (deploy + backups) Full admin panel (browse, query, backup) GitHub integration Yes (webhooks) Yes (webhooks) Yes (webhooks) Yes (OAuth + GitHub Actions) Multi-server Yes Yes (cluster mode) Yes Yes (unlimited servers) Monitoring Basic resource stats Basic Basic Agent-based + alerting + notifications Now let's dig deeper into each platform. ## Coolify: The Popular Open-Source PaaS ![Self-hosted PaaS platform dashboard showing container status](/app-screenshots/feature-container-status.jpg) **Coolify** is probably the most well-known open-source PaaS in 2026. Built by Andras Bacsai, it positions itself as a self-hosted alternative to Heroku and Netlify. Coolify runs as a web application on your server, providing a dashboard where you can connect GitHub repos, deploy containers, and manage databases. ### Coolify Strengths - **Active community** — large GitHub following and active Discord with quick support - **Multi-server support** — manage multiple VPS instances from one dashboard - **Built-in database provisioning** — deploy PostgreSQL, MySQL, Redis, and MongoDB alongside your apps - **Docker Compose support** — paste your existing compose file and deploy - **Free and open source** — Apache 2.0 license, completely free to self-host ### Coolify Limitations - **Runs on your server** — the Coolify dashboard itself consumes RAM and CPU on your VPS, reducing resources available for your apps - **Setup complexity** — requires installing and maintaining the platform on your server, including updates and security patches - **Limited template library** — around 30 one-click services, so many popular self-hosted apps require manual Docker configuration - **No built-in SSH terminal** — you still need a separate SSH client for server debugging - **Database management is basic** — can deploy databases but offers no query editor, table browser, or visual admin panel Coolify is a solid choice if you want a fully open-source, web-based PaaS and you're comfortable with the overhead of running the platform on your server. For a deeper comparison, see our [Server Compass vs Coolify](/compare/coolify) breakdown. ## CapRover: The Veteran Self-Hosted PaaS **CapRover** has been around longer than most of its competitors. It uses Nginx as its reverse proxy (rather than Traefik) and has a distinctive approach to deployments through its `captain-definition` file format. CapRover also supports Docker Swarm clustering out of the box, making it appealing for teams that need multi-node setups. ### CapRover Strengths - **Battle-tested** — one of the oldest self-hosted PaaS tools, with a mature and stable codebase - **Docker Swarm support** — native clustering for horizontal scaling across multiple servers - **One-click apps marketplace** — approximately 50 pre-built applications available - **Simple CLI** — deploy from your terminal with `caprover deploy` - **Completely free** — open source with no paid tier at all ### CapRover Limitations - **Dated UI** — the web interface feels functional but outdated compared to newer platforms - **Slower development pace** — updates and new features are less frequent than Coolify or Dokploy - **No Docker Compose support** — relies on its own `captain-definition` format, which means you often need to rewrite your deployment configs - **No database tooling** — no built-in database admin, query editor, or backup management - **Limited monitoring** — basic resource usage only, no alerting or notification integrations - **Runs on your server** — like Coolify, the dashboard consumes server resources CapRover is a dependable option if you need Docker Swarm clustering and prefer a simpler, no-frills tool. See our full [Server Compass vs CapRover](/compare/caprover) comparison for the detailed breakdown. ## Dokploy: The Modern Newcomer **Dokploy** is one of the newer entrants in the self-hosted PaaS space. It aims to be a lightweight, modern alternative with a clean UI and straightforward setup. Built with a focus on simplicity, Dokploy targets developers who want the fastest path from `git push` to a running app. ### Dokploy Strengths - **Modern, clean UI** — the newest interface design of the four platforms - **Lightweight** — smaller footprint than Coolify, consuming fewer server resources - **Docker Compose support** — deploy multi-container apps with standard compose files - **Database backups** — built-in backup and restore for PostgreSQL and MySQL - **Active development** — frequent updates and a growing community ### Dokploy Limitations - **Smallest template library** — roughly 20 templates, the fewest in this comparison - **Younger ecosystem** — fewer community resources, tutorials, and third-party integrations - **No SSH terminal** — no built-in way to access your server shell from the dashboard - **No file browser** — cannot browse or edit server files without separate SSH access - **Basic monitoring** — resource stats without configurable alerting - **Runs on your server** — same resource-sharing tradeoff as Coolify and CapRover Dokploy is a promising choice if you want a clean, modern self-hosted PaaS with minimal complexity. See our [Server Compass vs Dokploy](/compare/dokploy) comparison for more details. ## Server Compass: The Desktop PaaS with 247+ Templates **Server Compass** takes a fundamentally different approach. Instead of running a web dashboard on your server (consuming resources your apps could use), it runs as a **native desktop application** on your Mac, Windows, or Linux machine. It connects to your VPS over SSH and manages everything remotely — deployments, domains, databases, monitoring, and more. ![Server Compass template gallery with 247 one-click deploy templates](/app-screenshots/feature-templates.jpg) ### Server Compass Strengths - **Desktop app = zero server overhead** — nothing runs on your VPS except your actual apps. Every byte of RAM and CPU goes to your workloads, not a management dashboard - **247+ one-click templates** — the largest template library of any self-hosted PaaS, covering databases, CMS platforms, analytics tools, AI models, media servers, and more. See the full [template gallery](/templates) - **One-time $29 pricing** — no subscriptions, no per-seat fees, no bandwidth charges. Pay once, use forever. Compare that to [$600+/year on cloud PaaS platforms](/blog/why-self-hosting-saves-developers-600-per-year) - **Built-in database admin** — browse tables, run SQL queries, manage credentials, and [back up databases](/features/database-backup-restore) with one click. No need for separate tools like pgAdmin or Adminer - **Integrated SSH terminal** — a full [multi-tab SSH terminal](/features/ssh-terminal) with command suggestions, autocorrect, and downloadable logs - **File browser and editor** — browse, upload, download, and edit files on your server through the [built-in file manager](/features/file-browser) - **Advanced monitoring** — a [monitoring agent](/features/monitoring-agent) with configurable [alert rules](/features/alert-rules) and [notification channels](/features/notification-channels) (Slack, Discord, email, webhooks) - **GitHub Actions CI/CD** — [auto-generates GitHub Actions workflows](/features/github-actions-cicd) for zero-downtime blue-green deployments - **Docker Compose + registry deploys** — deploy from Dockerfiles, compose files, or pull pre-built images from [Docker Hub, GHCR, or any registry](/blog/docker-registry-deploy-trust-proxy) - **Server snapshots** — export your entire VPS configuration to an encrypted file for [disaster recovery or migration](/blog/server-snapshots-disaster-recovery) ### Server Compass Limitations - **Not open source** — proprietary software with a one-time purchase. If you require open-source licensing for compliance reasons, Coolify or CapRover may be better options - **No web dashboard** — you need the desktop app installed on your machine. There is no browser-based panel you can share with a team via URL (though the app supports multiple devices via [encrypted cross-device sync](/blog/cross-device-sync-encrypted)) - **No Docker Swarm clustering** — manages individual servers rather than orchestrating Swarm clusters. For multi-node Docker Swarm, CapRover has native support ## In-Depth Feature Comparison Let's break down the key areas where these platforms differ most. ### Templates and One-Click App Library The number of one-click templates determines how quickly you can deploy common self-hosted applications without writing Docker configuration from scratch. Platform Templates Categories Server Compass 247+ Databases, CMS, analytics, AI/LLM, media, DevOps, monitoring, security, and more CapRover ~50 Web apps, databases, CMS, some DevOps tools Coolify ~30 Databases, web apps, some popular services Dokploy ~20 Databases, common web services Server Compass's template library is roughly 5x larger than CapRover's and 8x larger than Dokploy's. This matters in practice: if you want to deploy something like [Plausible Analytics](/templates/plausible-analytics), [n8n](/templates/n8n), or [Ollama](/templates/ollama), Server Compass has a working template ready to go. With other platforms, you may need to write Docker Compose configuration yourself. You can browse the full [list of 247+ templates](/blog/50-one-click-deploy-templates-self-hosted). ### Deployment Methods All four platforms support deploying from Git repositories and Docker. The differences are in the details: - **Coolify** — GitHub/GitLab webhooks, Docker Compose, Dockerfiles, and static builds. Supports build packs (Nixpacks, Heroku buildpacks). - **CapRover** — GitHub webhooks, CLI deployment, and its own captain-definition format. No native Docker Compose support. - **Dokploy** — GitHub webhooks, Docker Compose, Dockerfiles. Clean Git integration with branch deployments. - **Server Compass** — GitHub OAuth + [GitHub Actions workflows](/features/github-actions-cicd), Docker Compose, [local Docker builds](/features/deploy-local-build), [registry pulls](/features/docker-registry-deploy), [direct upload](/features/upload-code-deploy), and PM2 deployments. The [Docker stack wizard](/features/docker-stack-wizard) auto-detects your project framework and generates the right configuration. ### Pricing: The Real Cost of Each Platform One of the most important factors is long-term cost. Here is what you actually pay: Platform Software cost Server cost (you provide) Year 1 total (1 VPS) Year 2+ total Coolify Free (self-hosted) ~$6/mo VPS ~$72 ~$72/yr CapRover Free ~$6/mo VPS ~$72 ~$72/yr Dokploy Free ~$6/mo VPS ~$72 ~$72/yr Server Compass $29 one-time ~$6/mo VPS ~$101 ~$72/yr Vercel Pro (for reference) $20/seat/mo N/A (managed) $240+ $240+/yr The open-source platforms (Coolify, CapRover, Dokploy) are free to use. Server Compass has a one-time $29 cost that pays for itself within the first month compared to cloud PaaS pricing. After year one, the ongoing cost is identical — just your VPS bill. The more important cost question is: **how much server overhead does the platform itself consume?** Coolify, CapRover, and Dokploy all run web dashboards on your server that use 200-500MB of RAM. On a budget VPS with 1-2GB total RAM, that is 10-50% of your resources going to the management tool instead of your apps. Server Compass's desktop approach means 100% of your VPS resources go to your workloads. For the full cost breakdown against cloud platforms, read our [self-hosting cost savings analysis](/blog/why-self-hosting-saves-developers-600-per-year) . ### Database Management If you self-host applications, you almost certainly self-host databases too. How well each platform handles database operations matters day-to-day: - **Coolify** — can deploy PostgreSQL, MySQL, Redis, and MongoDB as services. No visual query editor or table browser. - **CapRover** — no built-in database tooling at all. You deploy database containers manually and use external tools like pgAdmin. - **Dokploy** — deploys databases with basic backup/restore functionality. No query editor. - **Server Compass** — includes a full [database admin panel](/blog/database-admin-panel-vps) with credentials management, one-click backup/restore, [table browsing with search and pagination](/blog/auto-reconnect-database-table-browser), and a SQL query editor. Supports PostgreSQL, MySQL, and MongoDB. ### Monitoring and Alerting Knowing when something goes wrong on your server is critical. Here is how each platform handles monitoring: - **Coolify and Dokploy** — basic resource usage dashboards (CPU, memory, disk). No configurable alerting. - **CapRover** — minimal built-in monitoring. Most users pair it with external tools like Grafana + Prometheus. - **Server Compass** — installs a lightweight [monitoring agent](/features/monitoring-agent) that reports real-time metrics. You can configure [alert rules](/features/alert-rules) (e.g., CPU > 90% for 5 minutes) and route notifications to [Slack, Discord, email, or webhooks](/features/notification-channels). ## Which Self-Hosted PaaS Should You Choose? The right choice depends on your priorities. Here is a decision framework: ### Choose Coolify If: - Open-source licensing is a hard requirement - You want a web-based dashboard accessible from any browser - You need Nixpacks or Heroku buildpack support - You value a large community and active Discord for support - You are comfortable maintaining the platform software on your server ### Choose CapRover If: - You need Docker Swarm clustering for horizontal scaling - You prefer CLI-based deployment workflows - You want a mature, battle-tested platform with minimal surprises - You do not need Docker Compose support ### Choose Dokploy If: - You want the cleanest, most modern UI - You are deploying a small number of apps and do not need a large template library - You want a lightweight self-hosted PaaS with a small resource footprint - You prefer an actively-developed newcomer over established options ### Choose Server Compass If: - You want zero server overhead — every resource byte goes to your apps - You need the largest template library (247+ one-click deploys) for quickly spinning up self-hosted apps - You prefer one-time pricing over free-but-maintain-it-yourself - You want built-in database management, SSH terminal, file browser, and monitoring in one tool - You deploy to multiple servers and want to manage them all from one desktop app - You want [zero-downtime deployments](/features/zero-downtime) and [instant rollbacks](/features/rollback) out of the box - You are migrating from Vercel, Railway, or Render and want a familiar developer experience ## Migrating from Cloud PaaS to Self-Hosted If you are currently on Vercel, Railway, or Render and considering a switch to any of these self-hosted platforms, the migration is simpler than you might think. Every platform on this list supports standard Docker containers, which means your application does not need to change — only the deployment pipeline does. For a step-by-step migration guide from Vercel specifically, see our [complete self-hosted Vercel alternative guide](/blog/self-hosted-vercel-alternative-complete-guide) . If cost is your primary motivation, the [Vercel hidden costs breakdown](/blog/vercel-pricing-explained-hidden-costs) shows exactly where the money goes. The basic steps for any migration: 1. Get a VPS from Hetzner, DigitalOcean, or your preferred provider ($4-12/month for most workloads) 2. Install your chosen self-hosted PaaS (or download Server Compass and connect via SSH) 3. Containerize your app with a `Dockerfile` if you have not already 4. Connect your Git repository and deploy 5. Point your domain's DNS to your VPS and let the platform handle SSL With Server Compass, steps 2-5 are handled through the desktop UI with guided wizards. The [Docker stack wizard](/features/docker-stack-wizard) detects your framework automatically, and the [domain management panel](/features/domain-management) handles DNS verification and SSL certificate provisioning. ## Popular Stacks You Can Deploy Regardless of which platform you choose, self-hosted PaaS platforms support the same technology stacks you would use on cloud PaaS. Here are some popular configurations: - **Next.js + PostgreSQL** — the most common full-stack combo. Deploy with the [Next.js stack guide](/stacks/nextjs) or the [Next.js install page](/install/nextjs) - **Laravel + MySQL** — deploy PHP apps with the [Laravel stack](/stacks/laravel) - **Django + PostgreSQL** — Python web apps with the [Django stack](/stacks/django) - **Node.js + MongoDB** — JavaScript APIs and full-stack apps with the [MERN stack](/stacks/mern) Server Compass includes one-click templates for the database components of each stack (e.g., [PostgreSQL](/templates/postgresql), [MySQL](/templates/mysql), [MongoDB](/templates/mongodb), [Redis](/templates/redis)), so you can have your entire infrastructure running in minutes. ## Conclusion The self-hosted PaaS landscape in 2026 has matured significantly. Coolify, CapRover, Dokploy, and Server Compass each solve the same core problem — giving you a Vercel-like deployment experience on your own infrastructure — but they approach it differently. If open-source licensing is essential and you do not mind the management overhead, Coolify and CapRover are proven options. If you want a modern, minimal setup, Dokploy is worth watching. If you want the most complete toolset — 247+ templates, built-in database admin, SSH terminal, file browser, monitoring with alerting, and zero server overhead — all for a one-time $29 payment, [Server Compass](/) is the platform that covers the most ground in a single tool. Whichever platform you choose, moving off cloud PaaS to self-hosted infrastructure is one of the highest-ROI decisions a developer or small team can make. Your $6/month VPS is waiting. --- **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 VPS Control Panels for Developers in 2026 Source: https://servercompass.app/blog/best-vps-control-panels-developers-2026 Published: 2026-04-05 Tags: comparison, self-hosted, docker, server-management, hosting Compare the best VPS control panels for developers in 2026: CloudPanel, CyberPanel, Plesk, Webmin, and Server Compass. Features, pricing, ease of use, and which one fits your workflow. Managing a VPS without a control panel means wrestling with config files, memorizing terminal commands, and hoping you don't break something at 2 AM. A good server management panel eliminates that friction — but in 2026, the landscape has changed dramatically. Docker has become the default deployment method, developers expect modern UIs, and the old-guard panels haven't always kept up. This guide compares five VPS control panels that developers actually use today: CloudPanel, CyberPanel, Plesk, Webmin, and Server Compass. We'll cover features, pricing, ease of use, Docker support, and which panel fits which type of developer. If you've been searching for the right linux control panel for your servers, this breakdown will save you hours of research. ## What to Look for in a VPS Control Panel in 2026 Before comparing individual panels, here's what matters most for developers choosing a server management panel today: - **Docker and container support** — If you're deploying modern applications, native Docker support isn't optional anymore. Panels that treat containers as first-class citizens save you from managing Docker Compose files by hand. - **SSL and domain management** — Automatic Let's Encrypt certificates and easy domain configuration are table stakes. - **Database management** — Built-in tools for PostgreSQL, MySQL, or MongoDB mean you don't need separate admin tools. - **Security features** — Firewalls, fail2ban, SSH hardening, and security audits should be accessible without command-line expertise. - **Resource monitoring** — CPU, memory, disk, and network visibility so you know when your server is struggling. - **Pricing model** — Some panels are free but limited. Others charge monthly. A few offer one-time pricing. - **Target audience** — A panel built for WordPress hosting works differently than one built for Docker deployments. With those criteria in mind, let's examine each panel. ## 1\. CloudPanel — Lightweight and PHP-Focused ![VPS control panel comparison - server management dashboard](/app-screenshots/feature-server-overview.jpg) CloudPanel is a free, lightweight linux control panel built for PHP applications. It runs on Debian and Ubuntu, uses Nginx under the hood, and provides a clean web-based UI for managing sites, databases, and SSL certificates. ### Key Features - One-click installers for WordPress, Laravel, Drupal, and other PHP frameworks - Nginx with HTTP/2 and Brotli compression out of the box - MySQL and MariaDB management with phpMyAdmin alternative - Free Let's Encrypt SSL certificates - Node.js and Python support (limited compared to PHP) - Built-in file manager and cron job scheduler - Varnish Cache integration for performance ### Pricing CloudPanel is **completely free and open-source**. There's no paid tier, no feature gating, and no per-server license. This makes it an excellent choice for budget-conscious developers who primarily work with PHP. ### Limitations - No native Docker support — you're managing apps the traditional way - Heavily optimized for PHP; deploying Go, Rust, or Java apps requires manual work - No built-in reverse proxy management for containerized workloads - Web-based only — no desktop app, no offline access - Single-server only (no multi-server management) ### Best For PHP developers running WordPress, Laravel, or Drupal on a single VPS who want a free, lightweight panel with a modern UI. If Docker isn't part of your workflow, CloudPanel is hard to beat on value. ## 2\. CyberPanel — LiteSpeed-Powered Hosting Panel CyberPanel is an open-source control panel built on OpenLiteSpeed (or LiteSpeed Enterprise for the paid version). It positions itself as a high-performance alternative to cPanel with WordPress-centric features and built-in caching. ### Key Features - OpenLiteSpeed web server with LSCache for WordPress acceleration - One-click WordPress deployment with automatic optimization - Email hosting with SpamAssassin and DKIM - DNS management and Let's Encrypt SSL - Docker support via Docker Manager extension - Git-based deployments for PHP and Node.js projects - File manager, database management, and FTP accounts - Multi-site management from a single panel ### Pricing Plan Price Details Free (OpenLiteSpeed) $0/month Open-source, community support CyberPanel Enterprise $15-35/month LiteSpeed Enterprise, priority support ### Limitations - Docker support exists but feels bolted on — not a first-class workflow - The UI can feel cluttered, especially compared to newer panels - Primarily designed for shared hosting management, not developer workflows - LiteSpeed-specific caching and configuration can create vendor lock-in - Email hosting adds complexity most developers don't need ### Best For WordPress agencies and hosting providers who want high-performance LiteSpeed caching out of the box. If you're running multiple WordPress sites and need email hosting on the same server, CyberPanel covers a lot of ground for free. ## 3\. Plesk — The Enterprise-Grade Veteran Plesk has been around since 2001 and remains one of the most comprehensive server management panels available. It runs on both Linux and Windows, supports virtually every web technology, and comes with a marketplace of extensions for everything from WordPress toolkit management to Docker integration. ### Key Features - Support for PHP, Node.js, Python, Ruby, .NET, and Java - Docker extension with [container management](https://1devtool.com/features/docker-containers) UI - WordPress Toolkit with staging, cloning, and security hardening - Git integration with push-to-deploy - Email hosting with anti-spam and antivirus - Multi-server management (with Plesk Multi Server) - Extensive extension marketplace (300+ extensions) - Reseller and client management for hosting businesses ### Pricing Plan Price Details Web Admin ~$11/month Up to 10 domains, single admin Web Pro ~$19/month Up to 30 domains, reseller features Web Host ~$32/month Unlimited domains, full reseller panel ### Limitations - Monthly recurring cost that adds up across multiple servers - Docker support exists via extension but isn't deeply integrated - The UI shows its age in places despite recent updates - Resource-heavy — consumes more RAM than lightweight alternatives - Overkill for developers who just need to deploy a few apps - Steep learning curve for the full feature set ### Best For Hosting companies, agencies managing dozens of client sites, and enterprises that need Windows + Linux support on the same panel. If you're selling hosting or managing client websites, Plesk's reseller features justify the monthly cost. ## 4\. Webmin — The Open-Source Swiss Army Knife Webmin is the oldest and most configurable linux control panel on this list. First released in 1997, it provides a web interface for nearly every system administration task imaginable — from managing Apache configs to editing firewall rules to configuring RAID arrays. Its companion tool, Virtualmin, adds website hosting features on top. ### Key Features - Manages virtually every Linux service (Apache, Nginx, Postfix, BIND, Samba, and more) - Virtualmin add-on for website and domain management - Module system with hundreds of available modules - User and group management with fine-grained permissions - System monitoring, log viewing, and scheduled tasks - Package management (APT, YUM) through the UI - File manager, [terminal emulator](https://1devtool.com/blog/best-ai-terminal-emulator-for-developers-2026), and database access - Completely free and open-source ### Pricing Edition Price Details Webmin $0 System administration panel Virtualmin GPL $0 Web hosting features, community support Virtualmin Pro $7.50/month Premium features, script installers, support ### Limitations - The interface looks dated — functional but not modern - No native Docker or container management - Configuration overload: hundreds of options can overwhelm new users - Designed for system administrators, not application developers - No built-in reverse proxy management for modern web apps - No deployment workflows — you still manage everything manually ### Best For Linux system administrators who need deep control over every system service. If you're comfortable with Linux and want a UI for tasks you already know how to do in the terminal, Webmin is the most flexible option. It's not a deployment tool — it's a system administration tool. ## 5\. Server Compass — Desktop-First, Docker-Native Control Panel [Server Compass](/) takes a fundamentally different approach from every other panel on this list. Instead of running as a web application on your server (consuming resources and adding attack surface), it runs as a **desktop application** on your Mac, Windows, or Linux machine. It connects to your VPS via SSH and manages everything through that secure tunnel. Where traditional panels were built for the PHP hosting era, Server Compass was built for how developers actually work in 2026: Docker containers, [GitHub-connected deployments](/features/github-repo-deploy), and infrastructure-as-code workflows. ### Key Features - [166+ one-click Docker templates](/features/template-deployment) for deploying apps like PostgreSQL, Redis, n8n, Plausible, Ghost, and more - [Docker Stack Wizard](/features/docker-stack-wizard) for creating custom multi-container deployments with a visual editor - [Automatic SSL](/features/auto-ssl) via Traefik reverse proxy with Let's Encrypt certificates - [Built-in database admin panel](/features/db-admin) with SQL editor, table browser, and one-click backups for PostgreSQL, MySQL, and MongoDB - [Integrated SSH terminal](/features/ssh-terminal) with multi-tab support, command suggestions, and autocorrect - [GitHub Actions CI/CD integration](/features/github-actions) with auto-deploy on push - [Security audit tool](/features/security-audit) with fail2ban, UFW firewall, and SSH hardening - [Real-time container logs](/features/container-logs) and [resource monitoring](/features/resource-monitoring) - [File browser](/features/file-browser) with upload, download, and inline editing - [Zero-downtime deployments](/features/zero-downtime) with automatic rollback on failure - [Server snapshots](/features/server-snapshots) for disaster recovery and server migration - [Cron job management](/features/cron-scheduler) with a visual scheduler and execution logs ### Pricing Plan Price Details Free Trial $0 Full features, 1 server Pro (Lifetime) One-time payment Unlimited servers, all features, lifetime updates The one-time pricing model is a significant differentiator. There are no monthly fees, no per-server charges, and no feature gating. You pay once and manage as many servers as you need. Check the [pricing page](/pricing) for current rates. ### Why Desktop-First Matters Running a control panel as a web app on your server has real downsides that developers often overlook: - **Resource consumption** — Web-based panels run PHP, Node.js, or Go processes on your server 24/7, consuming RAM and CPU that could serve your applications - **Security surface** — Every web panel is another publicly accessible endpoint that can be targeted by attackers - **Server dependency** — If your server goes down, so does your panel. Server Compass works even when your server is unreachable, letting you diagnose and reconnect - **Multi-server management** — Instead of installing a panel on every server, you manage all your servers from one desktop app ### Limitations - Requires a desktop app installation (Mac, Windows, or Linux) - No web-based access from arbitrary browsers - Focused on Docker deployments — not designed for traditional PHP hosting - No email hosting features (by design — use a dedicated email service instead) ### Best For Developers and small teams who deploy with Docker and want a modern, fast control panel without monthly fees. Especially suited for indie developers, freelancers managing client servers, and teams running self-hosted tools like [n8n](/templates/n8n), [Plausible Analytics](/templates/plausible), [Ghost](/templates/ghost), and [PostgreSQL](/templates/postgresql) on their own infrastructure. ## Head-to-Head Comparison Table Here's how all five VPS control panels stack up across the criteria that matter most to developers: Feature CloudPanel CyberPanel Plesk Webmin Server Compass Price Free Free / $15-35/mo $11-32/month Free / $7.50/mo One-time payment Docker Support No Extension Extension No Native (core feature) One-Click Templates PHP apps only WordPress + few Via marketplace Virtualmin scripts 166+ Docker templates SSL Certificates Let's Encrypt Let's Encrypt Let's Encrypt + paid Manual / plugin Auto via Traefik Database Admin phpMyAdmin-style phpMyAdmin phpMyAdmin + extension Module-based Built-in with SQL editor Runs On Server (web UI) Server (web UI) Server (web UI) Server (web UI) Desktop (SSH tunnel) Server Resources Used ~200MB RAM ~300MB RAM ~500MB+ RAM ~100MB RAM 0 (runs on your machine) Multi-Server No No Paid add-on Webmin Cluster Yes (unlimited) CI/CD Integration No Basic Git deploy Git extension No GitHub Actions built-in Target Audience PHP developers WordPress/hosting Hosting companies Sysadmins Developers using Docker OS Support Debian/Ubuntu Ubuntu/CentOS/Alma Linux + Windows Most Linux distros Any Linux VPS (via SSH) ## Which VPS Control Panel Should You Choose? The right panel depends entirely on what you're deploying and how you work. Here's a quick decision framework: ### Choose CloudPanel if... - You run PHP applications (WordPress, Laravel, Drupal) - You want a free, lightweight panel with zero bloat - Docker is not part of your workflow - You manage a single server ### Choose CyberPanel if... - You want LiteSpeed caching for WordPress performance - You need email hosting on the same server - You manage multiple WordPress sites for clients - You want a free tier with decent hosting features ### Choose Plesk if... - You run a hosting business with reseller accounts - You need Windows Server support - You manage dozens of client websites with different tech stacks - Enterprise support and compliance matter to your organization ### Choose Webmin if... - You're a Linux sysadmin who wants a UI for system services - You need to manage BIND DNS, Postfix email, Samba, and similar services - You want maximum configuration flexibility - You don't mind a utilitarian interface ### Choose Server Compass if... - You deploy applications using Docker containers - You want one-click deployments from a [template library of 166+ apps](/templates) - You manage multiple VPS servers and want a single tool for all of them - You prefer one-time pricing over monthly subscriptions - You want [CI/CD integration with GitHub Actions](/features/github-actions) - You value a modern desktop experience over browser-based panels - You don't want the panel consuming resources on your server ## The Docker Factor: Why It Changes Everything The single biggest differentiator between these panels is how they handle Docker. In 2026, most developers deploy applications as containers. APIs, web apps, databases, background workers, monitoring tools — they all run in Docker. CloudPanel and Webmin have no Docker support. CyberPanel and Plesk have it as an extension, but it feels like an afterthought. You end up managing containers through the terminal anyway, which defeats the purpose of having a control panel. Server Compass was built around Docker from day one. The [Docker Stack Wizard](/features/docker-stack-wizard) lets you compose multi-container applications visually. The [template gallery](/features/template-deployment) deploys pre-configured stacks with one click. And features like [zero-downtime deployments](/features/zero-downtime), [instant rollbacks](/features/rollback), and [real-time container logs](/features/container-logs) are all designed around containerized workflows. If you're deploying traditional PHP or static sites, CloudPanel or CyberPanel will serve you well. But if Docker is how you ship software, the gap between Server Compass and the rest of this list is significant. You can read more about our Docker-first approach in [From PM2 to Docker: How We Rebuilt VPS Deployments from Scratch](/blog/docker-traefik-deployment-revolution). ## Security: Web Panels vs. Desktop Panels Security is worth calling out separately. Every web-based control panel (CloudPanel, CyberPanel, Plesk, Webmin) runs a web server on your VPS that's accessible from the internet. That means: - Another port open on your server (usually 8443 or similar) - Another web application that needs security updates - Another login page that can be brute-forced - Another potential vulnerability if the panel software has bugs Webmin and Plesk have both had critical security vulnerabilities in the past. CloudPanel and CyberPanel are newer but still represent additional attack surface. Server Compass eliminates this entire category of risk. There's no web server running on your VPS, no open port for the panel, and no login page exposed to the internet. All communication happens through your existing SSH connection. Combined with the built-in [security audit tool](/features/security-audit), [fail2ban management](/features/fail2ban), and [UFW firewall configuration](/features/ufw-firewall), you get better security with less effort. ## Already Using a Panel? How to Migrate If you're currently running CloudPanel, CyberPanel, or another web-based panel and want to move to a Docker-based workflow, the transition is straightforward. Server Compass even supports [coexisting with your existing Nginx or CloudPanel reverse proxy](/blog/nginx-caddy-cloudpanel-reverse-proxy) during the migration, so you don't have to switch everything at once. For a step-by-step approach: 1. Install Server Compass on your desktop and [connect to your server](/tutorials/connect-server-password) 2. Deploy new applications using Docker [templates](/templates) alongside your existing setup 3. Gradually migrate existing apps to containers as you're comfortable 4. Remove the old panel when you no longer need it The [migration wizard](/features/migration-wizard) can also help you move servers between VPS providers without reconfiguring everything from scratch. ## Conclusion The VPS control panel you choose should match how you actually build and deploy software. The traditional web-based panels — CloudPanel, CyberPanel, Plesk, and Webmin — each serve their audience well. CloudPanel excels at PHP hosting. CyberPanel brings LiteSpeed performance. Plesk covers enterprise and hosting business needs. Webmin gives sysadmins granular control. But if you're a developer in 2026 deploying with Docker, managing multiple servers, and looking for a tool that doesn't eat into your server resources or add security risk, [Server Compass](/) is the modern alternative. One-time pricing, a native desktop experience, [166+ one-click templates](/templates), and Docker-native workflows from the ground up. Ready to try a different kind of server management panel? [Start with the free trial](/pricing) and see how it compares to whatever you're using today. --- **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 Dokploy: Which Self-Hosted PaaS Should You Use? Source: https://servercompass.app/blog/coolify-vs-dokploy-self-hosted-paas-comparison Published: 2026-04-05 Tags: self-hosted, coolify, deployment, docker, comparison A detailed comparison of Coolify and Dokploy covering features, ease of use, pricing, Docker support, GitHub integration, and community. Find out which self-hosted PaaS fits your workflow in 2026. If you're looking for a self-hosted alternative to Vercel, Railway, or Heroku, two names come up constantly: **Coolify** and **Dokploy**. Both are open-source platforms that let you deploy applications to your own VPS with a web-based control panel — but they differ in meaningful ways when it comes to features, maturity, pricing, and developer experience. This guide breaks down the **coolify vs dokploy** debate across every dimension that matters: features, ease of use, Docker support, GitHub integration, pricing, and community. By the end, you'll know exactly which platform fits your workflow — and whether a third option might be worth considering. ## What Is Coolify? **Coolify** is an open-source, self-hosted PaaS built by Andras Bacsai. It installs on your server as a Docker-based panel and provides a web UI for deploying applications, databases, and services. Think of it as a self-hosted Heroku — you get Git push deployments, automatic SSL via Let's Encrypt, database provisioning, and a dashboard to manage everything. Coolify has been around since 2022 and is the more mature of the two platforms. Key highlights: - Supports Docker, Docker Compose, and Nixpacks-based builds - One-click service deployments (databases, Redis, monitoring tools) - Automatic SSL certificates via Let's Encrypt - Built-in webhook and GitHub/GitLab integration for auto-deploy - Server monitoring with resource usage dashboards - Backup scheduling for databases - Multi-server management from a single panel - Active development with regular releases ## What Is Dokploy? **Dokploy** is a newer open-source self-hosted PaaS that positions itself as a lightweight, simpler alternative to Coolify. Created by Mauricio Siu, it also runs as a Docker-based panel on your server and provides a web UI for deploying applications and databases. Dokploy launched more recently and has gained traction for its clean interface and straightforward approach. Key highlights: - Docker and Docker Compose deployments - Nixpacks support for automatic builds - Automatic SSL via Let's Encrypt with Traefik - GitHub, GitLab, and Bitbucket integration - Database management (PostgreSQL, MySQL, MongoDB, Redis) - Real-time deployment logs - Multi-server support via Docker Swarm - Clean, modern UI ## Feature-by-Feature Comparison Let's compare Coolify and Dokploy across the features that matter most for day-to-day deployment workflows. Feature Coolify Dokploy Platform type Server-installed web panel Server-installed web panel Open source Yes (Apache 2.0) Yes (Canary license) Build system Nixpacks, Dockerfiles, Docker Compose Nixpacks, Dockerfiles, Docker Compose Reverse proxy Traefik (default), Caddy option Traefik SSL certificates Automatic (Let's Encrypt) Automatic (Let's Encrypt) Database support PostgreSQL, MySQL, MongoDB, Redis, more PostgreSQL, MySQL, MongoDB, Redis Git providers GitHub, GitLab, Bitbucket GitHub, GitLab, Bitbucket Multi-server Yes (remote servers via SSH) Yes (Docker Swarm) Backup scheduling Built-in for databases Built-in for databases Monitoring Server resource dashboards Basic metrics One-click services 150+ service templates Fewer pre-built templates Webhooks Built-in Built-in API REST API available REST API available Maturity Since 2022, larger community Newer, growing fast On paper, these two platforms look remarkably similar. The real differences emerge in execution, ecosystem maturity, and the trade-offs each makes. ## Ease of Use ### Installation Both Coolify and Dokploy install via a single shell command that sets up Docker, pulls the panel image, and starts the web dashboard. The process takes 2-5 minutes on a fresh Ubuntu server. **Coolify** requires a minimum of 2 CPU cores and 2GB RAM for the panel alone. This is on top of whatever your applications need. On a budget VPS with 1GB RAM, Coolify can feel sluggish or fail to install entirely. **Dokploy** is generally lighter on resources, though it still installs a web panel, database, and Traefik on your server. Expect at least 512MB-1GB of RAM consumed by the panel infrastructure. Both platforms expose a web-based management panel on your server's IP or a domain you configure. This means your management interface is accessible over the internet — something to consider from a [security perspective](/blog/domain-security-headers-rate-limiting). ### Daily Workflow **Coolify's UI** is feature-rich but can feel overwhelming. The navigation has many sections — projects, environments, servers, sources, teams, and settings. For experienced developers, this depth is valuable. For beginners, there's a learning curve. **Dokploy's UI** is more streamlined. It focuses on the core workflow: create a project, add a service, deploy. The interface is cleaner and less cluttered, which makes it easier to pick up quickly. However, you may find yourself wanting features that Coolify already has. ## Docker Support Docker is the backbone of both platforms. Here's how they compare: ### Docker Compose Both Coolify and Dokploy support deploying applications from `docker-compose.yml` files. You can define multi-container stacks — for example, a web app with a database and cache — and deploy them as a unit. Coolify provides a built-in editor for Compose files and lets you configure environment variables, volumes, and networks through its UI. Dokploy offers a similar workflow but with a slightly more minimal interface. ### Dockerfile Builds Both platforms can build images from Dockerfiles in your repository. They also both support Nixpacks for automatic language detection and build configuration — similar to how Heroku buildpacks work. One consideration: since both platforms build images *on your server*, build times depend on your VPS hardware. A compute-intensive build on a 2-core VPS can spike CPU usage and temporarily slow down running applications. If you need to [build locally and deploy via SSH](/blog/local-build-deploy-vps), neither Coolify nor Dokploy supports that workflow natively. ### Container Management Coolify has more mature [container management](https://1devtool.com/features/docker-containers) with deployment history, rollback support, and detailed logs. Dokploy covers the basics — start, stop, restart, logs — but Coolify's container lifecycle management is more polished. ## GitHub Integration Git integration is where you'll notice meaningful differences in the Coolify vs Dokploy comparison. ### Coolify Coolify offers a GitHub App integration that provides webhook-based auto-deployments. However, **GitHub OAuth** — which allows you to browse and select repositories from the UI — requires a paid Coolify Cloud subscription or the paid self-hosted tier. On the free self-hosted version, you configure repositories manually via URL and deploy keys. ### Dokploy Dokploy supports GitHub, GitLab, and Bitbucket connections. You can configure Git providers through the settings panel and set up auto-deploy via webhooks. The setup involves creating SSH keys or personal access tokens manually. Like Coolify's free tier, you won't get a polished OAuth flow where you browse and pick repos from a dropdown. Both platforms support webhook-triggered deployments on push to a branch, which is the most common CI/CD pattern. If you want deeper [GitHub Actions integration](/features/github-actions) with generated workflows, neither platform provides that out of the box. ## Pricing Pricing is one of the most debated topics in the **coolify vs dokploy** discussion, and it's where they diverge significantly. ### Coolify Pricing - **Self-hosted (free)**: Full open-source version you install and maintain yourself. No GitHub OAuth, no priority support. - **Cloud ($5/month per server)**: Coolify hosts the management panel; you provide your servers. - **Self-hosted Pro ($5-350/month)**: Self-hosted but with GitHub OAuth, team features, and support tiers. The Basic tier ($5/mo) unlocks GitHub OAuth. Pro ($21/mo) adds team collaboration. Ultimate ($350/mo) includes white-label options. The free tier is genuinely free and functional, but if you want quality-of-life features like browsing your GitHub repos from the UI, you're looking at a monthly subscription. ### Dokploy Pricing - **Self-hosted (free)**: Fully open-source. All features included with no paywalled tiers. - **Dokploy Cloud**: Managed hosting option where Dokploy handles the panel infrastructure for a monthly fee. Dokploy's main advantage on pricing is simplicity: the self-hosted version includes all features. There's no tiered system gating features behind monthly subscriptions. For developers who want a **dokploy alternative** to Coolify's subscription model, this is a strong draw. ### The Hidden Cost: Server Resources Both platforms install a web panel, database, and reverse proxy on your server. This overhead typically consumes 500MB-2GB of RAM depending on the platform and configuration. On a $6/month VPS with 4GB RAM, that's 12-50% of your total memory consumed by the management tool itself — before you deploy a single application. This is a cost that doesn't show up on any pricing page but directly impacts how many applications you can run on your server. For a deeper look at how [self-hosting costs compare to PaaS platforms](/blog/why-self-hosting-saves-developers-600-per-year) , see our cost breakdown guide. ## Community and Ecosystem ### Coolify Coolify has the larger community by a significant margin. It has 35,000+ GitHub stars, an active Discord server with thousands of members, and regular feature releases. The project has been around longer, which means more tutorials, blog posts, and community-contributed service templates. If you run into an issue with Coolify, the chances of finding a solution in a GitHub issue, Discord thread, or blog post are high. The documentation is comprehensive, though it can lag behind the latest features. ### Dokploy Dokploy has a smaller but growing community. It has gained significant traction on GitHub and has an active Discord server. The project is moving quickly, with frequent releases and responsive maintainers. The trade-off is less third-party content. You'll find fewer tutorials and guides compared to Coolify. When something breaks, you may need to rely more on Discord support or reading the source code directly. ## Security Considerations Both Coolify and Dokploy share a fundamental architectural decision: they install a web-accessible management panel on your server. This means: - Your management dashboard is exposed to the internet - The panel itself is an attack surface that needs to be secured and kept updated - Panel bugs or vulnerabilities could compromise your entire server - You need to configure strong authentication and ideally restrict access by IP Both platforms support user authentication, and you should always set up HTTPS for the panel itself. Some developers put the management panel behind a VPN or [IP allowlist](/blog/domain-security-headers-rate-limiting) for extra protection. ## When to Choose Coolify Coolify is the better choice when: - **You need a mature ecosystem** — more service templates, larger community, more documentation - **You manage multiple remote servers** — Coolify's multi-server management via SSH is well-tested - **You need advanced features** — server monitoring dashboards, webhook integrations, and API access - **You want team collaboration** — Coolify's paid tiers offer role-based access and team management - **You're comfortable with a subscription** — the Pro features behind the paywall are genuinely useful ## When to Choose Dokploy Dokploy is the better choice when: - **You want all features free** — no paywalled tiers for the self-hosted version - **You prefer a simpler UI** — less overwhelming for beginners or solo developers - **You have limited server resources** — Dokploy is generally lighter on memory - **You use Docker Swarm** — Dokploy's multi-server approach uses Swarm natively - **You value a newer codebase** — less technical debt, potentially easier to contribute to ## Quick Comparison Summary Dimension Winner Notes Features Coolify More templates, monitoring, webhooks Ease of use Dokploy Cleaner UI, simpler onboarding Pricing (self-hosted) Dokploy All features free vs tiered model Docker support Tie Both handle Compose, Dockerfiles, Nixpacks GitHub integration Coolify (paid) OAuth browsing requires subscription Community Coolify Larger, more resources available Server footprint Dokploy Generally lighter on resources Multi-server Tie Different approaches (SSH vs Swarm) ## A Third Option: Skip the Server Panel Entirely Both Coolify and Dokploy share the same fundamental architecture: a web panel installed on your server that consumes resources, exposes a management surface to the internet, and requires ongoing maintenance and updates. If you've been comparing these two platforms, it's worth asking whether a server-installed panel is the right approach at all. [Server Compass](/) takes a fundamentally different approach. Instead of installing anything on your server, it's a **native desktop app** for Mac, Windows, and Linux that connects to your VPS over SSH. Your server stays clean — no panel, no database, no management daemon consuming RAM. The only thing on your server is Docker and your applications. Here's how it compares to both Coolify and Dokploy: - **Zero server footprint** — the app runs on your laptop, not your VPS. That means 100% of your server resources go to your applications. - **No exposed management panel** — no web dashboard for attackers to target. Your management interface lives on your local machine. - **One-time $29 payment** — no monthly subscriptions, no tiered feature access. You pay once and own it. Compare that to Coolify's $5-350/month for Pro features. See our [Coolify comparison](/compare/coolify) and [Dokploy comparison](/compare/dokploy) for full details. - **247+ one-click templates** — a larger [template library](/templates) than either Coolify or Dokploy, covering databases, CMS platforms, monitoring tools, AI applications, and more. - **Built-in GitHub OAuth** — browse and deploy from your repos without paying for a subscription tier. See our [GitHub integration](/features/github-oauth). - **GitHub Actions CI/CD generation** — Server Compass [generates GitHub Actions workflows](/features/github-actions) for [zero-downtime deployments](/features/zero-downtime), something neither Coolify nor Dokploy offers. - **Database admin panel** — browse tables, run queries, and manage backups for PostgreSQL, MySQL, and MongoDB directly from the [built-in database interface](/features/db-admin). - **Multi-server management** — manage all your servers from a single desktop app. No separate installation per server. If you're choosing between Coolify and Dokploy primarily for simplicity and cost, Server Compass offers a compelling **coolify alternative** and **dokploy alternative** that eliminates the server overhead entirely. You can explore the full [template gallery](/features/template-deployment) and [pricing details](/pricing) on the site. ## Final Verdict There is no single "best" self-hosted PaaS — it depends on your priorities. **Choose Coolify** if you want the most feature-rich, battle-tested open-source panel with a large community behind it. Be prepared to either stick to the free tier's limitations or pay for the Pro features you'll eventually want. **Choose Dokploy** if you prefer a leaner, fully-free self-hosted panel with a modern codebase and cleaner UI. Accept that the community and ecosystem are still catching up to Coolify. **Choose [Server Compass](/)** if you want to skip the server-installed panel model entirely, keep your VPS clean, and manage everything from a native desktop app with a one-time payment. It's a different architectural approach that avoids the trade-offs both Coolify and Dokploy share. Whichever path you choose, self-hosting your deployments on a [$5-20/month VPS](/blog/why-self-hosting-saves-developers-600-per-year) is dramatically cheaper than paying for [Vercel](/blog/vercel-pricing-explained-hidden-costs), [Railway](/blog/railway-pricing-what-youll-actually-pay), or [Heroku](/blog/true-cost-of-heroku-2026) at scale. The [self-hosted deployment landscape](/blog/best-self-hosted-deployment-platforms-2026) has never been stronger. --- **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. --- ## Deploy Apps on Hetzner: The Complete Beginner Guide Source: https://servercompass.app/blog/deploy-apps-hetzner-beginner-guide Published: 2026-04-05 Tags: hetzner, docker, deployment, vps-deploy, tutorials, getting-started, self-hosted A step-by-step beginner guide to deploying apps on Hetzner Cloud. Learn how to create an account, provision a VPS, connect via SSH, install Docker, and deploy your first application on one of the most affordable cloud providers. Hetzner Cloud is one of the best-kept secrets in the VPS world. While most beginners default to AWS or DigitalOcean, Hetzner offers significantly more computing power per dollar — and their European data centers are rock-solid. If you want to deploy an app on Hetzner but have never touched a VPS before, this guide walks you through every step from zero to a running application. By the end of this Hetzner VPS tutorial, you'll know how to create an account, provision a server, connect via SSH, install Docker, and deploy your first app. We'll also cover an easier alternative that skips the terminal entirely. ## Why Choose Hetzner for App Deployment Before we dive into the setup, here's why Hetzner stands out for developers deploying apps on a budget: - **Unbeatable pricing** — A 2-vCPU, 4GB RAM server costs around $4.50/month. The same specs on AWS EC2 or DigitalOcean cost 2-4x more. - **Included traffic** — Most plans include 20TB of outbound traffic. No surprise bandwidth bills. - **NVMe storage** — Fast SSD storage on all plans, not just premium tiers. - **Data centers in Europe and the US** — Falkenstein, Nuremberg, Helsinki, Ashburn (Virginia), and Hillsboro (Oregon). - **Simple, honest pricing** — No hidden fees, no confusing tier structures, no per-request charges. For comparison, a Hetzner CX22 (2 vCPUs, 4GB RAM, 40GB NVMe) costs about $4.50/month. A comparable DigitalOcean droplet costs $24/month. That's a massive difference, especially if you're running multiple apps or side projects. ### Hetzner Cloud Pricing at a Glance Plan vCPUs RAM Storage Price/Month CX11 1 2 GB 20 GB NVMe ~$3.50 CX22 2 4 GB 40 GB NVMe ~$4.50 CX32 4 8 GB 80 GB NVMe ~$8.50 CX42 8 16 GB 160 GB NVMe ~$16 All plans include 20TB of traffic. Even the smallest CX11 plan is enough to run a couple of [Docker-based applications](/templates). ## Step 1: Create a Hetzner Cloud Account Head to [hetzner.com/cloud](https://www.hetzner.com/cloud) and create an account. You'll need to: 1. Sign up with your email address 2. Verify your email 3. Add a payment method (credit card or PayPal) 4. Complete identity verification (may require a selfie with your ID for new accounts) Once verified, you'll land in the Hetzner Cloud Console. This is your dashboard for managing servers, networks, firewalls, and more. ## Step 2: Provision Your First VPS In the Hetzner Cloud Console, click **Create Server**. You'll need to make a few choices: ### Choose a Location Pick the data center closest to your users. If your audience is in Europe, choose Falkenstein (FSN), Nuremberg (NBG), or Helsinki (HEL). For US-based users, choose Ashburn (ASH) or Hillsboro (HIL). ### Choose an Operating System Select **Ubuntu 24.04**. It's the most widely supported Linux distribution, has the largest community, and virtually every tutorial you find online will use Ubuntu commands. Debian is a solid alternative if you prefer it. ### Choose a Server Plan For most apps, the **CX22** (2 vCPUs, 4GB RAM, ~$4.50/month) is the sweet spot. It can comfortably run multiple Docker containers, a reverse proxy, and a database. If you're just experimenting, the CX11 (1 vCPU, 2GB RAM, ~$3.50/month) works fine for a single lightweight app. ### Add an SSH Key (Recommended) Hetzner lets you add an SSH key during server creation. This is more secure than password authentication. If you don't have an SSH key yet, generate one on your local machine: ``` ssh-keygen -t ed25519 -C "your-email@example.com" ``` Then copy your public key: ``` cat ~/.ssh/id_ed25519.pub ``` Paste this into the SSH key field in the Hetzner server creation form. If you prefer password login instead, Hetzner will email you the root password after the server is created. ### Create the Server Give your server a name (e.g., `my-app-server`), review your choices, and click **Create & Buy now**. Your server will be ready in about 30 seconds. Copy the IP address — you'll need it for the next step. ## Step 3: Connect to Your Server via SSH Open a terminal on your local machine and connect to your new Hetzner server: ``` ssh root@YOUR_SERVER_IP ``` Replace `YOUR_SERVER_IP` with the IP address from the Hetzner Cloud Console. If you used an SSH key, you'll connect immediately. If you used a password, enter it when prompted. On your first connection, you'll see a fingerprint warning. Type `yes` to continue. You're now logged into your server. ### Initial Server Setup Before installing anything, update your system packages: ``` apt update && apt upgrade -y ``` For production servers, it's good practice to create a non-root user and configure a basic firewall. For this beginner guide, we'll keep it simple and work as root, but you can find more details in our [documentation](/docs). ## Step 4: Install Docker on Hetzner Docker is the standard way to deploy applications on a VPS. It packages your app and all its dependencies into a container that runs the same everywhere. Here's how to install it on your Hetzner server: ``` # Install Docker using the official convenience script curl -fsSL https://get.docker.com | sh # Verify the installation docker --version # Install Docker Compose plugin apt install docker-compose-plugin -y # Verify Compose docker compose version ``` That's it. Docker and Docker Compose are now installed and ready to use. The convenience script handles all the repository setup, GPG keys, and package installation automatically. If you want to learn more about deploying Docker containers on a VPS, check out our in-depth guide on [deploying Docker containers without Kubernetes](/blog/deploy-docker-containers-to-vps-without-kubernetes) . ## Step 5: Deploy Your First App on Hetzner Let's deploy a real application. We'll use [Uptime Kuma](/templates/uptime-kuma) as our example — it's a popular self-hosted monitoring tool that's perfect for a first deployment. ### Create a Docker Compose File Create a directory for your app and add a `docker-compose.yml` file: ``` mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma cat > docker-compose.yml << 'EOF' services: uptime-kuma: image: louislam/uptime-kuma:1 container_name: uptime-kuma restart: always ports: - "3001:3001" volumes: - uptime-kuma-data:/app/data volumes: uptime-kuma-data: EOF ``` ### Start the Application ``` docker compose up -d ``` The `-d` flag runs the container in the background. Docker will pull the image, create the container, and start it. Check that it's running: ``` docker compose ps ``` You should see the container in a "running" state. Open your browser and navigate to `http://YOUR_SERVER_IP:3001` — you'll see the Uptime Kuma setup page. ### Deploy More Applications The same pattern works for any Docker-based application. Here are some popular apps you can deploy on your Hetzner VPS: - [WordPress](/templates/wordpress) — The world's most popular CMS - [Ghost](/templates/ghost) — Modern publishing platform - [n8n](/templates/n8n) — Workflow automation (like Zapier, but self-hosted) - [Plausible Analytics](/templates/plausible) — Privacy-friendly Google Analytics alternative - [PostgreSQL](/templates/postgresql) — Production-grade database You can browse our full catalog of [200+ one-click deploy templates](/templates) for more options. ## Adding a Domain and SSL Certificate Running apps on an IP address and port number isn't ideal for production. You'll want a domain name with HTTPS. This requires a reverse proxy — a server that sits in front of your apps, routes traffic by domain name, and handles SSL certificates. [Traefik](/templates/traefik) is the easiest reverse proxy to use with Docker. It automatically discovers your containers and provisions free SSL certificates from Let's Encrypt. Setting up Traefik manually involves configuring Docker labels, creating a Traefik configuration file, and managing certificate storage. While doable, it's one of the more complex parts of self-hosting. If you want SSL and domains without the YAML configuration, keep reading for the easy path. ## Essential Hetzner Tips for Beginners ### Configure the Hetzner Firewall Hetzner Cloud offers a free cloud firewall. Go to **Firewalls** in the Cloud Console and create one with these rules: - **SSH (TCP 22)** — Allow from your IP only, or from anywhere if you use SSH keys - **HTTP (TCP 80)** — Allow from anywhere - **HTTPS (TCP 443)** — Allow from anywhere Apply this firewall to your server. This blocks all other incoming traffic by default, which is an important security baseline. ### Enable Backups Hetzner offers automated server backups for 20% of the server price (about $0.90/month for a CX22). Enable this under your server's **Backups** tab. It takes daily snapshots so you can restore your server if something goes wrong. For application-level backups, consider backing up your Docker volumes and database dumps separately. Our guide on [encrypted cloud backups](/blog/cloud-backup-s3-encrypted) covers this in detail. ### Monitor Server Resources Hetzner provides basic graphs for CPU, disk, and network usage in the Cloud Console. For more detailed monitoring, you can deploy [Uptime Kuma](/templates/uptime-kuma) (as we did above) or [Grafana](/templates/grafana) with Prometheus for full observability. ## The Easy Way: Deploy on Hetzner with Server Compass The steps above work perfectly, but they assume you're comfortable with SSH and the command line. If you'd rather skip the terminal entirely — or you just want a faster workflow — [Server Compass](/) is a visual server management tool that connects to your Hetzner VPS and handles everything through a desktop app. Here's what the workflow looks like with Server Compass: 1. **Connect your Hetzner server** — Enter your server IP and password (or SSH key). Server Compass connects in seconds. No terminal required. See our [connection tutorial](/tutorials/connect-server-password) for a walkthrough. 2. **Deploy apps from templates** — Browse [200+ one-click templates](/features/template-deployment) and deploy WordPress, PostgreSQL, n8n, or any Docker app with a single click. Environment variables, volumes, and networking are pre-configured. 3. **Add domains with automatic SSL** — Point your domain to your server IP and add it in Server Compass. [SSL certificates](/features/auto-ssl) are provisioned automatically via Let's Encrypt. 4. **Manage everything visually** — Monitor [container status](/features/container-status), view [logs](/features/container-logs), [roll back deployments](/features/rollback), and [browse files](/features/file-browser) — all from a clean desktop interface. Server Compass works with any VPS provider, not just Hetzner. If you already have servers on DigitalOcean, Vultr, or Linode, you can manage them all from the same app. We have a dedicated tutorial showing how to [self-host Supabase on a Hetzner VPS](/tutorials/self-host-supabase) using Server Compass, with no terminal commands at all. ## Hetzner vs Other VPS Providers How does Hetzner stack up against the competition? Here's a quick comparison for equivalent server specs (2 vCPUs, 4GB RAM): Provider Monthly Cost Traffic Included Storage **Hetzner CX22** ~$4.50 20 TB 40 GB NVMe DigitalOcean $24 4 TB 80 GB SSD Vultr $18 3 TB 80 GB NVMe Linode $24 4 TB 80 GB SSD AWS Lightsail $20 4 TB 80 GB SSD Hetzner's pricing is dramatically lower with generous traffic allowances. The trade-off is fewer data center locations compared to AWS or DigitalOcean, but for most applications serving European or US audiences, Hetzner's coverage is more than sufficient. ## What Should You Deploy on Hetzner? With a Hetzner VPS and Docker, you can run almost anything. Here are some popular use cases: - **Web apps and APIs** — Deploy [Next.js](/install/nextjs), [Laravel](/install/laravel), [Django](/install/django), or Express.js applications - **Self-hosted SaaS alternatives** — Run [n8n](/templates/n8n) instead of Zapier, [Plausible](/templates/plausible) instead of Google Analytics, or [NocoDB](/templates/nocodb) instead of Airtable - **Development tools** — Host your own [Gitea](/templates/gitea) instance, CI/CD pipeline, or [container management dashboard](/templates/portainer) - **Databases** — Run [PostgreSQL](/templates/postgresql), [MySQL](/templates/mysql), or [Redis](/templates/redis) without managed database pricing - **AI and machine learning** — Self-host [Ollama for local AI models](/blog/self-host-ollama-vps-one-click) on Hetzner's dedicated CPU servers ## Troubleshooting Common Issues ### Cannot Connect via SSH If `ssh root@YOUR_SERVER_IP` hangs or times out: - Verify the IP address is correct in the Hetzner Cloud Console - Check that the server status is "Running" - Make sure your Hetzner firewall allows TCP port 22 - If using a password, check your email for the root password from Hetzner ### App Not Accessible in Browser If your app is running but you cannot access it at `http://YOUR_SERVER_IP:PORT`: - Ensure the Hetzner firewall allows the port your app is running on - Verify the container is running with `docker compose ps` - Check container logs with `docker compose logs` - Make sure the container is binding to `0.0.0.0`, not `127.0.0.1` ### Running Out of Disk Space Docker images and unused containers can fill up your disk. Clean them with: ``` docker system prune -a --volumes ``` For a more visual approach, our guide on [disk management](/blog/disk-management-lock-server-vps) shows how Server Compass scans your VPS for reclaimable space and lets you clean up with one click. ## Next Steps You now have a working Hetzner VPS with Docker, ready to deploy any application. Here are some recommended next steps to level up your setup: - [Deploy Docker containers to VPS without Kubernetes](/blog/deploy-docker-containers-to-vps-without-kubernetes) — Deep dive into Docker Compose, Traefik, and production best practices - [Host multiple WordPress sites on one server](/blog/beginner-host-multiple-wordpress-sites-no-terminal) — Beginner guide to running multiple sites on your Hetzner VPS - [Set up GitHub auto-deploy](/features/github-repo-deploy) — Push to GitHub, auto-deploy to your Hetzner server - [Enable zero-downtime deployments](/blog/zero-downtime-deployment-traefik-vps) — Ship updates without dropping requests - [Lock down your domains](/blog/domain-security-headers-rate-limiting) — Security headers, rate limiting, and IP allowlists Hetzner gives you powerful, affordable infrastructure. Pair it with Docker for containerized deployments, or use [Server Compass](/) to manage everything visually without ever opening a terminal. Either way, you're in control of your own servers — no vendor lock-in, no per-seat pricing, and no surprise bills. --- **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. 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. --- ## How to Deploy Apps on a VPS Using Docker Compose Source: https://servercompass.app/blog/deploy-apps-vps-docker-compose Published: 2026-04-05 Tags: docker, deployment, vps-deploy, self-hosted, tutorials A practical guide to deploying applications on a VPS with Docker Compose. Learn how to write compose files, deploy multi-container apps, manage services, and follow production best practices. Docker Compose is the easiest way to deploy multi-container applications on a VPS. Instead of running long `docker run` commands with dozens of flags, you define your entire stack in a single YAML file and bring it up with one command. Whether you're deploying a web app with a database, a reverse proxy with multiple services, or a full monitoring stack, Docker Compose keeps everything declarative, reproducible, and version-controlled. This guide walks you through everything you need to know about using Docker Compose to deploy apps on a VPS — from the basics of compose files to production-grade deployment strategies. By the end, you'll be able to deploy any application stack to your server with confidence. ## What Is Docker Compose and Why Use It on a VPS? Docker Compose is a tool for defining and running multi-container Docker applications. You describe your services, networks, and volumes in a `docker-compose.yml` file, then use a single command to create and start everything. On a VPS, Docker Compose solves three problems that make raw Docker painful: - **Reproducibility** — your entire stack is defined in code. No more "it worked on my machine" issues when deploying to a server. - **Multi-container orchestration** — most apps need more than one container. A web app typically requires the app itself, a database, a cache, and a reverse proxy. Compose manages all of them together. - **Simplified management** — start, stop, restart, and update your entire stack with single commands instead of managing containers individually. For VPS deployments, Docker Compose hits the sweet spot between simplicity and power. You don't need Kubernetes for most workloads — a single compose file on a $10-20/month VPS handles more traffic than most applications will ever see. For a deeper dive on this trade-off, see our guide on [deploying Docker containers to a VPS without Kubernetes](/blog/deploy-docker-containers-to-vps-without-kubernetes). ## Prerequisites Before you start, make sure you have: - A VPS running Ubuntu 22.04 or later (any provider works — DigitalOcean, Hetzner, Linode, etc.) - SSH access to your server - Docker Engine installed (version 24.0+) - Docker Compose v2 (ships with Docker Engine as `docker compose`) If you don't have Docker installed yet, here is the quickest way to get it on Ubuntu: ``` # Install Docker using the official convenience script curl -fsSL https://get.docker.com | sh # Add your user to the docker group (log out and back in after this) sudo usermod -aG docker $USER # Verify installation docker --version docker compose version ``` Docker Compose v2 is included with modern Docker installations as a CLI plugin. You use it as `docker compose` (with a space) instead of the older standalone `docker-compose` binary. ## Docker Compose File Basics Every Docker Compose deployment starts with a `docker-compose.yml` file (or simply `compose.yml` — both names work). This file defines your services, networks, and volumes using YAML syntax. Here is a minimal compose file that runs a Node.js app with a PostgreSQL database: ``` services: app: image: node:20-alpine working_dir: /app volumes: - ./src:/app ports: - "3000:3000" environment: DATABASE_URL: postgres://myuser:mypass@db:5432/mydb depends_on: db: condition: service_healthy restart: unless-stopped db: image: postgres:16-alpine environment: POSTGRES_USER: myuser POSTGRES_PASSWORD: mypass POSTGRES_DB: mydb volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"] interval: 5s timeout: 3s retries: 5 restart: unless-stopped volumes: pgdata: ``` Let's break down the key sections: ### Services Each service is a container. The `app` service runs your application and the `db` service runs PostgreSQL. Services can reference each other by name — notice how `app` connects to the database using `db` as the hostname in the connection string. ### Volumes Named volumes like `pgdata` persist data across container restarts and rebuilds. Without a volume, your database data would disappear every time you redeploy. Bind mounts (`./src:/app`) map directories from your host into the container, useful for development but typically avoided in production. ### depends\_on and Healthchecks The `depends_on` directive with `condition: service_healthy` ensures your app only starts after the database passes its health check. Without this, your app might try to connect to a database that hasn't finished initializing. ### Restart Policies Setting `restart: unless-stopped` ensures containers automatically restart after a crash or server reboot. This is essential for production — without it, your services stay down until you manually restart them. ## Writing Production-Ready Compose Files The basic example above works for development, but a production Docker Compose deployment on a VPS needs additional configuration. Here is a more complete example with a web app, database, Redis cache, and Traefik reverse proxy: ``` {`services: traefik: image: traefik:v3.0 command: - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=you@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - letsencrypt:/letsencrypt restart: unless-stopped app: build: context: . dockerfile: Dockerfile environment: DATABASE_URL: postgres://myuser:\$@db:5432/mydb REDIS_URL: redis://redis:6379 NODE_ENV: production labels: - "traefik.enable=true" - "traefik.http.routers.app.rule=Host(\\\`app.example.com\\\`)" - "traefik.http.routers.app.entrypoints=websecure" - "traefik.http.routers.app.tls.certresolver=letsencrypt" depends_on: db: condition: service_healthy redis: condition: service_started restart: unless-stopped db: image: postgres:16-alpine environment: POSTGRES_USER: myuser POSTGRES_PASSWORD: \$ POSTGRES_DB: mydb volumes: - pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U myuser -d mydb"] interval: 10s timeout: 5s retries: 5 restart: unless-stopped redis: image: redis:7-alpine volumes: - redisdata:/data restart: unless-stopped volumes: pgdata: redisdata: letsencrypt:`} ``` This compose file adds several production-critical elements: - **Traefik reverse proxy** — handles SSL certificate provisioning via Let's Encrypt and routes traffic to your app. No need to configure Nginx manually. See our post on [zero-downtime deployments with Traefik](/blog/zero-downtime-deployment-traefik-vps) for more details. - **Environment variable interpolation** — secrets like `${DB_PASSWORD}` are pulled from a `.env` file rather than hardcoded in the compose file. - **Named volumes for all stateful data** — PostgreSQL data, Redis data, and SSL certificates all survive container rebuilds. - **Health checks** — the database includes a health check so dependent services wait until it's actually ready. ## Deploying to Your VPS With your compose file ready, deploying to a VPS is straightforward. Here is the typical workflow: ### Step 1: Transfer Your Files to the Server Copy your project files to the VPS using `scp`, `rsync`, or a Git clone: ``` # Option A: Clone from Git (recommended) ssh user@your-server git clone https://github.com/youruser/yourapp.git cd yourapp # Option B: Copy files with rsync rsync -avz --exclude node_modules --exclude .git \\ ./ user@your-server:~/yourapp/ ``` ### Step 2: Create Your Environment File Create a `.env` file on the server with your production secrets: ``` # .env (on the server, NOT committed to Git) DB_PASSWORD=your-secure-password-here SECRET_KEY=your-app-secret-key ``` Docker Compose automatically reads `.env` files in the same directory as your compose file. Never commit this file to version control. ### Step 3: Pull Images and Start Services ``` # Pull the latest images docker compose pull # Start all services in detached mode docker compose up -d # Verify everything is running docker compose ps ``` The `-d` flag runs containers in the background. Without it, your terminal would be attached to the container logs and services would stop when you disconnect. ### Step 4: Verify Your Deployment ``` # Check service status docker compose ps # View logs (all services) docker compose logs # View logs for a specific service docker compose logs app --tail 50 --follow # Test the endpoint curl -I https://app.example.com ``` ## Managing Docker Compose Services Once your stack is running, you need to know how to manage it day-to-day. Here are the essential Docker Compose commands for a production VPS: Command Purpose `docker compose ps` Show running services and their status `docker compose logs -f` Stream logs from all services `docker compose restart app` Restart a single service `docker compose stop` Stop all services (keeps containers) `docker compose down` Stop and remove containers and networks `docker compose down -v` Stop and also remove volumes (destroys data) `docker compose pull && docker compose up -d` Update to latest images and restart `docker compose exec app sh` Open a shell inside a running container ### Updating Your Application To deploy an update, pull the latest code, rebuild if needed, and restart: ``` # If using a Git-based workflow cd ~/yourapp git pull origin main # Rebuild and restart (only recreates changed services) docker compose up -d --build # If using pre-built images, just pull and restart docker compose pull docker compose up -d ``` Docker Compose is smart about updates — it only recreates containers whose configuration or image has actually changed. Your database container won't restart just because you updated your app code. ### Viewing Resource Usage Monitor how much CPU and memory your services consume: ``` # Live resource stats docker stats # Disk usage by Docker docker system df ``` For production monitoring, consider deploying a dedicated monitoring stack. Server Compass provides built-in [resource monitoring](/features/resource-monitoring) that shows CPU, memory, and disk usage per container in a visual dashboard — no extra setup required. ## Docker Compose Production Best Practices Running Docker Compose in production on a VPS is different from local development. Here are the practices that separate a fragile deployment from a reliable one: ### 1\. Pin Image Versions Never use the `latest` tag in production. A new upstream release could break your application without warning. ``` # Bad - unpredictable image: postgres:latest # Good - predictable image: postgres:16.2-alpine ``` ### 2\. Use .env Files for Secrets Keep secrets out of your compose file and your Git history. Use `.env` files that only exist on the server: ``` # docker-compose.yml environment: DB_PASSWORD: \$ # .env (gitignored) DB_PASSWORD=super-secret-value ``` For a more robust approach, Server Compass includes an [encrypted environment vault](/features/environment-vault) that stores secrets locally with AES encryption and lets you reuse them across deployments. ### 3\. Set Resource Limits Prevent a single container from consuming all available resources on your VPS: ``` services: app: deploy: resources: limits: cpus: "1.0" memory: 512M reservations: cpus: "0.25" memory: 128M ``` ### 4\. Configure Logging Docker containers can generate massive log files that fill your disk. Set log rotation to prevent this: ``` services: app: logging: driver: "json-file" options: max-size: "10m" max-file: "3" ``` This caps each service at 30MB of logs (3 files at 10MB each). For disk management tips beyond logging, check out our guide on [reclaiming disk space on your VPS](/blog/disk-management-lock-server-vps). ### 5\. Add Healthchecks to Every Service Healthchecks let Docker (and your reverse proxy) know when a service is actually ready to receive traffic, not just running: ``` services: app: healthcheck: test: ["CMD", "curl", "-f", "http://localhost:3000/health"] interval: 30s timeout: 10s retries: 3 start_period: 40s ``` ### 6\. Use Named Volumes for Persistent Data Always use named volumes rather than bind mounts for production data. Named volumes are managed by Docker and survive `docker compose down` (unless you pass `-v`): ``` volumes: pgdata: # Database files uploads: # User uploads letsencrypt: # SSL certificates ``` ### 7\. Automate Backups Volumes persist your data, but they don't protect you from disk failure or accidental deletion. Set up regular backups of your database and critical volumes: ``` # Dump PostgreSQL to a file docker compose exec db pg_dumpall -U myuser > backup.sql # Back up a named volume docker run --rm -v pgdata:/data -v $(pwd):/backup \\ alpine tar czf /backup/pgdata-backup.tar.gz /data ``` If managing backup scripts feels tedious, Server Compass offers [one-click database backups](/features/database-backups) with optional [encrypted cloud storage](/blog/cloud-backup-s3-encrypted) to S3-compatible providers. ## Simplifying Docker Compose Deploys with Server Compass The command-line workflow described above works, but it requires SSH access, manual file transfers, and memorizing a set of Docker commands. If you manage multiple apps or servers, this gets repetitive fast. [Server Compass](/) is a desktop application that gives you a visual interface for Docker Compose deployments on any VPS. Instead of writing YAML by hand and running commands over SSH, you get: - **A built-in Compose editor** — a [full-featured YAML editor](/features/docker-compose-editor) for writing and validating Docker Compose files visually. Syntax highlighting, auto-completion, and instant error feedback mean fewer typos and faster iteration. - **247+ ready-made templates** — the [template library](/features/template-deployment) covers databases like [PostgreSQL](/templates/postgresql) and [Redis](/templates/redis), applications like [Ghost](/templates/ghost) and [n8n](/templates/n8n), monitoring tools like [Grafana](/templates/grafana) and [Uptime Kuma](/templates/uptime-kuma), and much more. Each template is a production-tuned Docker Compose configuration you can deploy with one click. - **A Docker Stack Wizard** — the [multi-step wizard](/features/docker-stack-wizard) walks you through building a compose deployment from scratch. Pick your source (Git repo, Dockerfile, or registry image), configure environment variables, set up domains, and deploy — all without touching a terminal. - **Zero-downtime redeployments** — update your app without dropping connections. Server Compass uses [blue-green deployment with Traefik](/blog/zero-downtime-deployment-traefik-vps) to switch traffic only after the new container passes health checks. - **[Container management](https://1devtool.com/features/docker-containers)** — start, stop, restart, view logs, and open a shell into any container from the GUI. No SSH required. ![Server Compass Docker Compose Editor with syntax highlighting and validation](/app-screenshots/feature-compose-editor.jpg) This is especially useful if you're managing multiple compose stacks across multiple servers. Server Compass connects to all your VPS instances from a single desktop app and lets you deploy, monitor, and manage everything in one place. ## Common Docker Compose Patterns for VPS Deployments Here are some patterns you will use repeatedly when deploying apps to a VPS with Docker Compose: ### Web App + Database + Reverse Proxy This is the most common pattern. Your app talks to a database over the internal Docker network, and a reverse proxy (Traefik or Nginx) handles SSL and routes external traffic: ``` {`services: proxy: image: traefik:v3.0 ports: ["80:80", "443:443"] volumes: - /var/run/docker.sock:/var/run/docker.sock:ro # ... Traefik config app: build: . labels: - "traefik.enable=true" - "traefik.http.routers.app.rule=Host(\\\`myapp.com\\\`)" depends_on: [db] db: image: postgres:16-alpine volumes: [pgdata:/var/lib/postgresql/data] volumes: pgdata:`} ``` ### Multiple Apps Behind a Shared Proxy Run multiple applications on the same VPS by sharing a single Traefik instance. Each app gets its own compose file but connects to the shared proxy network: ``` {`# In each app's docker-compose.yml networks: default: proxy: external: true services: app: networks: [default, proxy] labels: - "traefik.docker.network=proxy" - "traefik.http.routers.myapp.rule=Host(\\\`myapp.com\\\`)"`} ``` This pattern lets you host dozens of apps on a single VPS, each with its own domain and automatic SSL. It is the pattern that Server Compass uses internally for its [template-based deployments](/features/template-deployment). ### Scheduled Tasks Run periodic jobs alongside your main application: ``` services: app: build: . # ... main app config worker: build: . command: node worker.js depends_on: [db, redis] scheduler: build: . command: node cron.js depends_on: [db] ``` ## Troubleshooting Common Issues When a Docker Compose deployment on your VPS doesn't work as expected, these commands help you diagnose the problem: ### Container Won't Start ``` # Check logs for the failing service docker compose logs app --tail 100 # Check if the container exited with an error docker compose ps -a # Inspect the container for configuration issues docker inspect $(docker compose ps -q app) ``` ### Port Conflicts ``` # Find what's using a port sudo lsof -i :80 sudo ss -tlnp | grep :80 # Use a different host port in your compose file ports: - "8080:80" # Map host 8080 to container 80 ``` ### Out of Disk Space ``` # Check Docker disk usage docker system df # Remove unused images, containers, and networks docker system prune -f # Remove unused volumes (careful - this deletes data) docker volume prune -f ``` ### Services Can't Communicate If containers can't reach each other, check that they're on the same Docker network: ``` # List networks docker network ls # Inspect a network to see connected containers docker network inspect yourapp_default ``` By default, Docker Compose creates a shared network for all services in a compose file. Services reference each other by their service name (e.g., `db` for the database, `redis` for the cache). ## Next Steps You now have a solid foundation for deploying applications on a VPS with Docker Compose. Here are some next steps to harden your setup: - [Set up CI/CD with GitHub Actions](/blog/self-hosted-cicd-github-actions-vps) to automate deployments when you push to your main branch - [Configure security headers and rate limiting](/blog/domain-security-headers-rate-limiting) on your domains - [Create server snapshots](/blog/server-snapshots-disaster-recovery) for disaster recovery - Deploy a monitoring stack with [Grafana](/templates/grafana) and [Uptime Kuma](/templates/uptime-kuma) to keep an eye on your services If you want to skip the command-line setup and manage Docker Compose deployments visually, [give Server Compass a try](/). It connects to any VPS over SSH and gives you a complete GUI for Docker deployments, database management, domain configuration, and more — all from your desktop. --- **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. 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. --- ## How to Deploy Next.js to a VPS with Docker (Step-by-Step Guide) Source: https://servercompass.app/blog/deploy-nextjs-docker-vps-step-by-step Published: 2026-04-05 Tags: nextjs, docker, deployment, vps-deploy, tutorials A practical, step-by-step guide to deploying your Next.js application to a VPS using Docker. Covers Dockerfile creation, Docker Compose setup, Traefik reverse proxy with automatic SSL, and how Server Compass can simplify the entire process. You built a Next.js app. It works perfectly on `localhost:3000`. Now you need to get it running on a real server. Vercel is the obvious choice, but maybe you want predictable costs, full control over your infrastructure, or the ability to run other services alongside your app. That is where deploying Next.js to a VPS with Docker comes in. This guide walks you through every step of a Docker-based Next.js VPS deployment — from configuring your app for production to running it behind a reverse proxy with automatic SSL. If you want to skip the manual work entirely, we will also show you how [Server Compass](/) can do this in a few clicks. ## Why Use Docker for Next.js Deployment? You could deploy Next.js directly on your VPS with Node.js and PM2. But Docker gives you several advantages that matter in production: - **Reproducible builds** — your app runs in the exact same environment everywhere, whether it is your laptop, staging, or production. - **Isolation** — your Next.js app, database, and other services run in separate containers. A crashing app does not take down your database. - **Easy rollbacks** — rolling back is as simple as pointing to a previous Docker image tag. - **Multi-service deployments** — need PostgreSQL, Redis, or a background worker alongside your app? Docker Compose handles all of it in one file. - **Smaller production images** — with multi-stage builds and Next.js standalone mode, your final image can be under 200 MB. For a broader look at all deployment methods (PM2, Docker, Nginx), check out our [complete Next.js VPS deployment guide](/blog/deploy-nextjs-to-vps-complete-guide) . ## Prerequisites Before you start, make sure you have: - **A VPS** — any provider works: Hetzner, DigitalOcean, Linode, or Vultr. At least 1 GB RAM and 1 vCPU. Ubuntu 22.04 or 24.04 recommended. - **Docker and Docker Compose installed** — we will cover this below. - **A Next.js application** — either a new `create-next-app` project or an existing app. - **A domain name** — pointed to your server's IP with an A record (needed for SSL). - **SSH access** — root or sudo access to your server. ## Step 1: Configure Next.js for Standalone Output Next.js has a `standalone` output mode that creates a minimal production bundle with only the files and dependencies your app actually needs. This is critical for Docker because it keeps your image size small and your build fast. Open `next.config.ts` (or `next.config.js`) and add the output setting: ``` // next.config.ts import type { NextConfig } from 'next' const nextConfig: NextConfig = { output: 'standalone', } export default nextConfig ``` Run `npm run build` locally to verify it works. You should see a `.next/standalone` directory after the build completes. This folder contains a self-contained Node.js server that does not need `node_modules`. ## Step 2: Write a Multi-Stage Dockerfile A multi-stage Dockerfile keeps your production image lean by separating the build environment from the runtime environment. Create a `Dockerfile` in your project root: ``` # Stage 1: Install dependencies FROM node:20-alpine AS deps WORKDIR /app COPY package.json package-lock.json* ./ RUN npm ci # Stage 2: Build the application FROM node:20-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN npm run build # Stage 3: Production runtime FROM node:20-alpine AS runner WORKDIR /app ENV NODE_ENV=production ENV NEXT_TELEMETRY_DISABLED=1 # Create a non-root user RUN addgroup --system --gid 1001 nodejs RUN adduser --system --uid 1001 nextjs # Copy the standalone output COPY --from=builder /app/public ./public COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./ COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static USER nextjs EXPOSE 3000 ENV PORT=3000 ENV HOSTNAME="0.0.0.0" CMD ["node", "server.js"] ``` This Dockerfile does three things: 1. **deps stage** — installs `node_modules` in an isolated layer so dependency changes do not invalidate the build cache. 2. **builder stage** — copies your source code and runs `npm run build` to generate the standalone output. 3. **runner stage** — copies only the standalone output, static files, and public assets into a minimal Alpine image. No `node_modules`, no source code. The final image is typically 150–200 MB depending on your dependencies, compared to 1+ GB for a naive single-stage build. Also create a `.dockerignore` file to keep your build context small: ``` node_modules .next .git *.md .env*.local ``` ## Step 3: Set Up Docker Compose Docker Compose lets you define your entire stack in a single YAML file. Create a `docker-compose.yml` in your project root: ``` version: '3.8' services: nextjs: build: context: . dockerfile: Dockerfile ports: - "3000:3000" environment: - NODE_ENV=production - DATABASE_URL=\$ restart: unless-stopped ``` Test it locally first: ``` docker compose build docker compose up -d ``` Open `http://localhost:3000` to verify your app runs correctly inside the container. If you see your app, the Docker setup is working. ## Step 4: Install Docker on Your VPS SSH into your server and install Docker: ``` ssh root@your-server-ip # Install Docker curl -fsSL https://get.docker.com | sh # Verify installation docker --version docker compose version ``` If you are on Ubuntu, this installs Docker Engine and the Compose plugin. You should see version numbers for both commands. ## Step 5: Transfer Your Code and Build You have two options for getting your code onto the server: ### Option A: Clone from Git If your code is on GitHub (or any Git host), clone it directly: ``` git clone https://github.com/your-username/your-nextjs-app.git cd your-nextjs-app ``` ### Option B: Upload with rsync If your code is not in a repository, use `rsync` from your local machine: ``` rsync -avz --exclude node_modules --exclude .next \\ ./ root@your-server-ip:/opt/your-nextjs-app/ ``` Once the code is on the server, create your environment file: ``` cd /opt/your-nextjs-app cp .env.example .env nano .env # Add your production values ``` Then build and start: ``` docker compose build docker compose up -d ``` Your Next.js app is now running on port 3000. But you still need a reverse proxy and SSL. ## Step 6: Add a Reverse Proxy with SSL You do not want users accessing your app via `http://your-ip:3000`. You need a reverse proxy that handles HTTPS and routes traffic to your container. Traefik is an excellent choice because it integrates natively with Docker and handles Let's Encrypt certificates automatically. Update your `docker-compose.yml` to include Traefik: ``` {`version: '3.8' services: traefik: image: traefik:v3.0 command: - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=you@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - letsencrypt:/letsencrypt restart: unless-stopped nextjs: build: context: . dockerfile: Dockerfile labels: - "traefik.enable=true" - "traefik.http.routers.nextjs.rule=Host(\`yourdomain.com\`)" - "traefik.http.routers.nextjs.entrypoints=websecure" - "traefik.http.routers.nextjs.tls.certresolver=letsencrypt" - "traefik.http.services.nextjs.loadbalancer.server.port=3000" environment: - NODE_ENV=production restart: unless-stopped volumes: letsencrypt:`} ``` Replace `you@example.com` with your email and `yourdomain.com` with your actual domain. Make sure your domain's A record points to your server's IP address before running this. Deploy the updated stack: ``` docker compose up -d ``` Traefik will automatically obtain a Let's Encrypt certificate and start serving your Next.js app over HTTPS. Visit `https://yourdomain.com` — you should see your app with a valid SSL certificate. For more details on reverse proxy configuration, including using Nginx or Caddy instead of Traefik, see our guide on [using your existing reverse proxy with Server Compass](/blog/nginx-caddy-cloudpanel-reverse-proxy) . ## Step 7: Manage Environment Variables Never bake secrets into your Docker image. Use Docker Compose's `.env` file support instead: ``` # .env (on your server, NOT in git) DATABASE_URL=postgresql://user:pass@db:5432/myapp NEXTAUTH_SECRET=your-secret-here NEXTAUTH_URL=https://yourdomain.com ``` Reference these in your `docker-compose.yml`: ``` services: nextjs: environment: - DATABASE_URL=\$ - NEXTAUTH_SECRET=\$ - NEXTAUTH_URL=\$ ``` Docker Compose automatically reads the `.env` file from the same directory. Make sure `.env` is in your `.gitignore` so secrets never get committed. ## Step 8: Add a Database (Optional) Most Next.js apps need a database. Add PostgreSQL to your Docker Compose stack: ``` services: # ... traefik and nextjs from above ... db: image: postgres:16-alpine environment: - POSTGRES_USER=\$ - POSTGRES_PASSWORD=\$ - POSTGRES_DB=\$ volumes: - postgres_data:/var/lib/postgresql/data restart: unless-stopped volumes: letsencrypt: postgres_data: ``` Your Next.js app can connect to the database using the Docker service name: `postgresql://user:pass@db:5432/myapp`. No need to expose port 5432 to the internet — containers on the same Docker network can communicate directly. Need to manage your database visually? Check out the [Server Compass database admin panel](/features/database-admin) or our guide to [self-hosting PostgreSQL on your VPS](/blog/how-to-self-host-postgresql-on-your-vps) . ## Step 9: Deploy Updates When you push new code, SSH into your server and rebuild: ``` cd /opt/your-nextjs-app git pull docker compose build docker compose up -d ``` For zero-downtime deployments, you can use Docker's rolling update strategy or Traefik's health checks. We cover this in detail in our [zero-downtime deployment guide](/blog/zero-downtime-deployment-traefik-vps) . For automated deployments, you can set up a [GitHub Actions CI/CD pipeline](/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments) that builds and deploys on every push to main. ## Common Issues and Fixes Problem Cause Fix Build fails with "out of memory" VPS has less than 1 GB RAM Add swap space: `fallocate -l 2G /swapfile` `.next/standalone` missing Forgot `output: 'standalone'` Add it to `next.config.ts` and rebuild Images and static files 404 Missing `public` and `.next/static` copy Verify COPY lines in Dockerfile runner stage SSL certificate not issued DNS not pointing to server Check A record and wait for propagation Container exits immediately Missing environment variables Check logs: `docker compose logs nextjs` ## The Easy Way: Deploy Next.js with Server Compass The steps above work, but they involve writing Dockerfiles, configuring Traefik, managing environment variables, and SSH-ing into your server every time you deploy. If you would rather skip all of that, [Server Compass](/) handles the entire workflow from a desktop app. Here is what the process looks like: 1. [Connect your VPS](/tutorials/connect-server-password) — paste your server IP and password. No SSH key setup required. 2. [Connect your GitHub repo](/features/github-repo-deploy) — select your Next.js repository and branch. 3. Deploy — Server Compass detects Next.js, generates the Dockerfile and Docker Compose configuration, sets up Traefik with automatic SSL, and deploys your app. You also get [a visual Docker stack wizard](/features/docker-stack-wizard), [real-time container logs](/features/container-logs), [encrypted environment variable management](/features/environment-vault), and [staging and preview environments](/blog/staging-preview-environments-activity-logs) . Updates deploy with a click — no more SSH, no more remembering `docker compose build && docker compose up -d`. There is a dedicated [Next.js deployment video tutorial](/tutorials/deploy-nextjs) if you prefer watching over reading. ## Next.js Docker Deployment vs Vercel Wondering whether this is worth the effort compared to just using Vercel? Here is a quick comparison: Factor Vercel VPS + Docker Monthly cost (production app) $20+/user + usage fees $5–$10 flat Bandwidth Metered (overage charges) Unmetered on most VPS plans Deploy time Git push (automatic) Git pull + rebuild (or automated via CI/CD) Run other services alongside No Yes (databases, Redis, workers) Vendor lock-in High (edge functions, ISR caching) None Infrastructure control None Full root access For a deeper analysis, read our [Server Compass vs Vercel comparison](/compare/vercel) and [Vercel pricing breakdown](/blog/vercel-pricing-explained-hidden-costs) . ## Production Checklist Before calling your deployment production-ready, walk through this checklist: - `output: 'standalone'` is set in `next.config.ts` - Dockerfile uses multi-stage build with a non-root user - `.dockerignore` excludes `node_modules`, `.next`, and `.git` - Environment variables are in `.env`, not hardcoded in the image - SSL is configured via Traefik (or Nginx/Caddy) with auto-renewal - Database volumes are persistent (not lost on container restart) - `restart: unless-stopped` is set on all services - You can rebuild and redeploy without downtime ## Next Steps You now have a Next.js app running on your own VPS with Docker, a reverse proxy, and automatic SSL. Here are some things to explore next: - Set up [CI/CD with GitHub Actions](/blog/self-hosted-cicd-github-actions-vps) to automate deployments on every push. - Add [more Docker containers](/blog/deploy-docker-containers-to-vps-without-kubernetes) to your stack — Redis, background workers, monitoring tools. - Configure [security headers and rate limiting](/blog/domain-security-headers-rate-limiting) for your domain. - Set up [encrypted backups](/blog/cloud-backup-s3-encrypted) so you can recover from any disaster. Or skip the manual configuration entirely. [Try Server Compass](/) and deploy your Next.js app to any VPS in minutes — no Dockerfiles, no YAML, no SSH. --- **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. --- ## Docker Compose Templates for Popular Developer Tools (Ready to Use) Source: https://servercompass.app/blog/docker-compose-templates-developer-tools Published: 2026-04-05 Tags: docker, templates, self-hosted, deployment, tutorials Copy-paste Docker Compose templates for Grafana, Prometheus, PostgreSQL, Redis, Nginx, Traefik, n8n, Metabase, and more. Each template includes working YAML and setup instructions. Every developer has been there: you need a monitoring stack, a database, or a reverse proxy running in Docker, and you spend 30 minutes piecing together a `docker-compose.yml` from scattered documentation, outdated blog posts, and GitHub issues. The YAML is wrong. The volumes are misconfigured. The environment variables have changed since the last major release. This post gives you **ready-to-use Docker Compose templates** for the most popular developer tools. Each template is tested, uses named volumes for persistence, and includes brief setup instructions so you can go from zero to running in under five minutes. And if you'd rather skip the YAML entirely, [Server Compass ships 247+ one-click templates](/templates) that handle all of this for you — environment variables, volumes, networking, and port mappings pre-configured. ## Databases ### PostgreSQL The most popular open-source relational database. This template includes persistent storage and a health check so dependent services can wait for the database to be ready. ``` version: "3.8" services: postgres: image: postgres:16-alpine container_name: postgres restart: unless-stopped environment: POSTGRES_USER: admin POSTGRES_PASSWORD: changeme POSTGRES_DB: appdb volumes: - postgres_data:/var/lib/postgresql/data ports: - "5432:5432" healthcheck: test: ["CMD-SHELL", "pg_isready -U admin -d appdb"] interval: 10s timeout: 5s retries: 5 volumes: postgres_data: ``` After running `docker compose up -d`, connect with any PostgreSQL client using `localhost:5432`. Change `POSTGRES_PASSWORD` before deploying to a server. See our [PostgreSQL template page](/templates/postgresql) or the full [self-host PostgreSQL guide](/blog/how-to-self-host-postgresql-on-your-vps) for production hardening tips. ### Redis In-memory data store used for caching, session management, and message brokering. This template enables append-only file persistence so your data survives restarts. ``` version: "3.8" services: redis: image: redis:7-alpine container_name: redis restart: unless-stopped command: redis-server --appendonly yes --requirepass changeme volumes: - redis_data:/data ports: - "6379:6379" volumes: redis_data: ``` Connect with `redis-cli -a changeme` or use it as a backend for your application. The `--appendonly yes` flag enables AOF persistence. Check the [Redis template](/templates/redis) for the one-click version. ## Monitoring and Observability ### Grafana The standard for dashboards and data visualization. Grafana connects to dozens of data sources including Prometheus, InfluxDB, PostgreSQL, and Elasticsearch. ``` version: "3.8" services: grafana: image: grafana/grafana:latest container_name: grafana restart: unless-stopped environment: GF_SECURITY_ADMIN_USER: admin GF_SECURITY_ADMIN_PASSWORD: changeme GF_INSTALL_PLUGINS: grafana-clock-panel,grafana-piechart-panel volumes: - grafana_data:/var/lib/grafana ports: - "3000:3000" volumes: grafana_data: ``` Open `http://localhost:3000` and log in with the credentials above. Add your first data source under **Connections > Data Sources**. Our [Grafana installation tutorial](/tutorials/install-grafana-vps) walks through connecting it to Prometheus and building your first dashboard. ### Prometheus Pull-based metrics collection and alerting. Prometheus scrapes targets at regular intervals and stores time-series data locally. ``` version: "3.8" services: prometheus: image: prom/prometheus:latest container_name: prometheus restart: unless-stopped volumes: - prometheus_data:/prometheus - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro ports: - "9090:9090" command: - "--config.file=/etc/prometheus/prometheus.yml" - "--storage.tsdb.retention.time=30d" volumes: prometheus_data: ``` You will need a `prometheus.yml` configuration file in the same directory: ``` global: scrape_interval: 15s scrape_configs: - job_name: "prometheus" static_configs: - targets: ["localhost:9090"] ``` Access the Prometheus UI at `http://localhost:9090`. Add additional scrape targets for your applications, Node Exporter, or cAdvisor. See the [Prometheus setup tutorial](/tutorials/install-prometheus-vps) for a full walkthrough. ### Grafana + Prometheus Stack The most common monitoring combo. This Docker Compose template runs both services on the same network so Grafana can reach Prometheus without exposing Prometheus to the public internet. ``` version: "3.8" services: prometheus: image: prom/prometheus:latest container_name: prometheus restart: unless-stopped volumes: - prometheus_data:/prometheus - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro ports: - "9090:9090" command: - "--config.file=/etc/prometheus/prometheus.yml" - "--storage.tsdb.retention.time=30d" grafana: image: grafana/grafana:latest container_name: grafana restart: unless-stopped environment: GF_SECURITY_ADMIN_USER: admin GF_SECURITY_ADMIN_PASSWORD: changeme volumes: - grafana_data:/var/lib/grafana ports: - "3000:3000" depends_on: - prometheus volumes: prometheus_data: grafana_data: ``` After both services start, add Prometheus as a data source in Grafana using `http://prometheus:9090` as the URL (Docker's internal DNS resolves the service name). Both templates are available as [one-click deploys](/templates/grafana) in Server Compass. ## Reverse Proxies ### Nginx The most widely used reverse proxy and web server. This template serves static files or proxies requests to backend services. ``` version: "3.8" services: nginx: image: nginx:alpine container_name: nginx restart: unless-stopped volumes: - ./nginx.conf:/etc/nginx/nginx.conf:ro - ./html:/usr/share/nginx/html:ro ports: - "80:80" - "443:443" ``` Create an `nginx.conf` file for your specific use case. For reverse proxying to a backend app on port 3000: ``` events { worker_connections 1024; } http { server { listen 80; server_name yourdomain.com; location / { proxy_pass http://host.docker.internal:3000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } } } ``` For a deeper dive into Nginx with SSL and domain configuration, read our [guide on deploying with Nginx](/blog/deploy-react-app-to-vps-with-nginx) or see how [Server Compass integrates with existing Nginx setups](/blog/nginx-caddy-cloudpanel-reverse-proxy). ### Traefik A modern reverse proxy built for containers. Traefik automatically discovers services via Docker labels and provisions Let's Encrypt SSL certificates. ``` version: "3.8" services: traefik: image: traefik:v3.0 container_name: traefik restart: unless-stopped command: - "--api.insecure=true" - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=you@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" - "8080:8080" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - letsencrypt_data:/letsencrypt volumes: letsencrypt_data: ``` The Traefik dashboard is available at `http://localhost:8080`. To expose a service through Traefik, add Docker labels to it: ``` {`labels: - "traefik.enable=true" - "traefik.http.routers.myapp.rule=Host(\`app.yourdomain.com\`)" - "traefik.http.routers.myapp.entrypoints=websecure" - "traefik.http.routers.myapp.tls.certresolver=letsencrypt"`} ``` Server Compass uses Traefik under the hood for [zero-downtime deployments](/blog/zero-downtime-deployment-traefik-vps) and [per-domain security headers](/blog/domain-security-headers-rate-limiting). It configures all of this automatically so you never have to write Traefik labels by hand. ## Automation and Business Intelligence ### n8n A self-hosted workflow automation platform — think Zapier, but running on your own server with no per-execution limits. ``` version: "3.8" services: n8n: image: n8nio/n8n:latest container_name: n8n restart: unless-stopped environment: N8N_BASIC_AUTH_ACTIVE: "true" N8N_BASIC_AUTH_USER: admin N8N_BASIC_AUTH_PASSWORD: changeme N8N_HOST: localhost N8N_PORT: "5678" N8N_PROTOCOL: http WEBHOOK_URL: http://localhost:5678/ volumes: - n8n_data:/home/node/.n8n ports: - "5678:5678" volumes: n8n_data: ``` Open `http://localhost:5678` to access the workflow editor. n8n supports 400+ integrations out of the box. For a production setup with a custom domain, follow our [n8n self-hosting tutorial](/tutorials/self-host-n8n-vps) or use the [n8n one-click template](/templates/n8n). ### Metabase Open-source business intelligence that lets non-technical team members query databases and build dashboards without writing SQL. ``` version: "3.8" services: metabase: image: metabase/metabase:latest container_name: metabase restart: unless-stopped environment: MB_DB_TYPE: postgres MB_DB_DBNAME: metabase MB_DB_PORT: "5432" MB_DB_USER: metabase MB_DB_PASS: changeme MB_DB_HOST: postgres volumes: - metabase_data:/metabase-data ports: - "3000:3000" depends_on: postgres: condition: service_healthy postgres: image: postgres:16-alpine container_name: metabase-db restart: unless-stopped environment: POSTGRES_USER: metabase POSTGRES_PASSWORD: changeme POSTGRES_DB: metabase volumes: - metabase_pg_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U metabase -d metabase"] interval: 10s timeout: 5s retries: 5 volumes: metabase_data: metabase_pg_data: ``` Metabase starts at `http://localhost:3000`. The setup wizard walks you through connecting your data sources. This template uses PostgreSQL as Metabase's internal database instead of the default H2 file database, which is recommended for production. See the [Metabase template](/templates/metabase) for the one-click version. ## More Essential Templates ### Uptime Kuma A self-hosted uptime monitoring tool with a clean UI. Supports HTTP, TCP, DNS, and ping checks with notifications via Slack, Discord, Telegram, and more. ``` version: "3.8" services: uptime-kuma: image: louislam/uptime-kuma:latest container_name: uptime-kuma restart: unless-stopped volumes: - uptime_kuma_data:/app/data ports: - "3001:3001" volumes: uptime_kuma_data: ``` Access the dashboard at `http://localhost:3001` and create your first monitor. Uptime Kuma is one of the most popular self-hosted tools for good reason — it replaces paid services like Pingdom or UptimeRobot. ### Portainer A web UI for managing Docker containers, images, volumes, and networks. Useful for visual [container management](https://1devtool.com/features/docker-containers) on your server. ``` version: "3.8" services: portainer: image: portainer/portainer-ce:latest container_name: portainer restart: unless-stopped volumes: - /var/run/docker.sock:/var/run/docker.sock - portainer_data:/data ports: - "9443:9443" volumes: portainer_data: ``` Open `https://localhost:9443` to create your admin account. Portainer gives you a GUI for Docker, but if you want a more complete server management experience with deployment pipelines, database admin, and domain management built in, take a look at [Server Compass's template deployment feature](/features/template-deployment). ### MinIO S3-compatible object storage you can self-host. Use it for file uploads, backups, or as a storage backend for other services. ``` version: "3.8" services: minio: image: minio/minio:latest container_name: minio restart: unless-stopped command: server /data --console-address ":9001" environment: MINIO_ROOT_USER: admin MINIO_ROOT_PASSWORD: changeme123 volumes: - minio_data:/data ports: - "9000:9000" - "9001:9001" volumes: minio_data: ``` The MinIO console is at `http://localhost:9001` and the S3 API is on port `9000`. Use any S3-compatible client or SDK to interact with it. ## Docker Compose Tips for Production These templates work for local development out of the box. Before deploying to a VPS, keep these best practices in mind: - **Change all default passwords.** Every template above uses `changeme` as a placeholder. Use a password manager or `openssl rand -base64 32` to generate strong credentials. - **Pin image versions.** Replace `:latest` with a specific tag like `postgres:16.3-alpine` or `grafana/grafana:11.1.0`. This prevents unexpected breaking changes on restart. - **Use named volumes.** All templates above use named Docker volumes. Never use bind mounts to random host directories — named volumes are managed by Docker and easier to back up. - **Set resource limits.** Add `deploy.resources.limits` to prevent a single container from consuming all your server's memory. - **Add a reverse proxy.** Do not expose application ports directly. Put [Nginx](/blog/nginx-caddy-cloudpanel-reverse-proxy) or [Traefik](/blog/zero-downtime-deployment-traefik-vps) in front for SSL termination and domain routing. - **Set up backups.** Docker volumes are not backed up by default. Use `docker run --rm -v volume_name:/data -v $(pwd):/backup alpine tar czf /backup/backup.tar.gz /data` or a [cloud backup solution](/blog/cloud-backup-s3-encrypted). For a deeper guide on deploying Docker Compose to a VPS, see our [Docker deployment guide without Kubernetes](/blog/deploy-docker-containers-to-vps-without-kubernetes) and the companion post on [deploying apps with Docker Compose](/blog/deploy-apps-vps-docker-compose). ## Skip the YAML: 247+ One-Click Templates Writing Docker Compose files by hand works, but it gets tedious when you are deploying multiple services across multiple servers. Every tool has its own environment variables, volume paths, and port conventions to remember. [Server Compass](https://servercompass.app) ships with [247+ one-click templates](/templates) for databases, monitoring tools, CMS platforms, automation tools, and more. Each template is pre-configured with the correct environment variables, persistent volumes, and networking. You pick the app, click Deploy, and it is running on your VPS in under a minute. The [built-in Docker Compose editor](/features/docker-compose-editor) also lets you write and edit compose files visually if you need custom configurations. And the [Docker Stack Wizard](/features/docker-stack-wizard) walks you through multi-container deployments step by step. If you are managing one or more VPS instances and deploying containerized apps regularly, these templates are a starting point — but a tool that handles the entire lifecycle from deployment to monitoring to backups will save you significantly more time. [Give Server Compass a try](https://servercompass.app). --- **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. --- ## How to Deploy Docker Apps to a VPS: The Complete Production Guide Source: https://servercompass.app/blog/how-to-deploy-docker-apps-to-vps Published: 2026-04-05 Tags: docker, deployment, vps-deploy, tutorials, self-hosted, ssh, getting-started A step-by-step guide to deploying Docker containers on a VPS. Covers SSH setup, Docker installation, running containers, Docker Compose, reverse proxy configuration, and managing production deployments. You have a Docker app running locally and a VPS sitting idle. The gap between the two is smaller than you think. No container orchestration platform, no managed service bills, no vendor lock-in—just Docker on a Linux server you control. This guide walks you through every step of a real Docker production deployment: connecting to your VPS over SSH, installing Docker, running your first container, composing multi-service apps, setting up a reverse proxy with automatic SSL, and managing deployments over time. Whether you are shipping a Node.js API, a Python web app, or a full-stack project, the workflow is the same. ## Prerequisites Before you deploy Docker apps to your VPS, make sure you have: - A VPS from any provider (DigitalOcean, Hetzner, Linode, Vultr, or others) running Ubuntu 22.04 or later - A domain name pointed at your server's IP address (for SSL) - A terminal on your local machine (macOS Terminal, Windows PowerShell, or a Linux shell) - Your application with a working `Dockerfile` Most VPS providers give you a server with root SSH access in under a minute. A $5–$10/month plan with 1–2 GB RAM is enough to run several Docker containers in production. ## Step 1: Connect to Your VPS via SSH Every Docker VPS hosting workflow starts with SSH. When your provider creates the server, you get an IP address and either a root password or an SSH key. Connect from your terminal: ``` ssh root@your-server-ip ``` If you used a password during setup, you will be prompted to enter it. For key-based authentication (recommended for production), add your public key to the server: ``` # On your local machine, copy your public key to the server ssh-copy-id root@your-server-ip ``` ### Secure Your SSH Access For any Docker production deployment, locking down SSH is non-negotiable. Create a non-root user and disable password authentication: ``` # Create a deploy user adduser deploy usermod -aG sudo deploy # Copy your SSH key to the new user rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy # Disable password authentication sudo sed -i 's/#PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config sudo systemctl restart sshd ``` From now on, connect as your deploy user: `ssh deploy@your-server-ip`. This keeps your server secure while still giving you full access to manage Docker containers. If you prefer a visual approach, [Server Compass lets you connect to your VPS](/tutorials/connect-server-password) without memorizing SSH commands. Enter your server IP and credentials in the GUI, and you are connected. ## Step 2: Install Docker on Your VPS Docker is the engine that runs your containers. Install Docker Engine and Docker Compose on Ubuntu with the official repository: ``` # Update packages and install prerequisites sudo apt update sudo apt install -y ca-certificates curl gnupg # Add Docker's official GPG key sudo install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg sudo chmod a+r /etc/apt/keyrings/docker.gpg # Add the Docker repository echo \\ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \\ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \\ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # Install Docker Engine and Compose plugin sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # Add your user to the docker group (avoids needing sudo) sudo usermod -aG docker $USER ``` Log out and back in for the group change to take effect, then verify: ``` docker --version docker compose version ``` You should see Docker Engine 24+ and Compose v2+. Your VPS is now ready for Docker VPS hosting. ## Step 3: Run Your First Docker Container With Docker installed, deploy a container to confirm everything works. Start with a simple Nginx web server: ``` docker run -d --name my-nginx -p 80:80 nginx:alpine ``` Visit `http://your-server-ip` in a browser. You should see the Nginx welcome page. That single command pulled the image, created a container, and bound it to port 80. To deploy your own application, push your code to the server, build the Docker image, and run it: ``` # Clone your repo on the server git clone https://github.com/your-username/your-app.git cd your-app # Build the Docker image docker build -t my-app:latest . # Run the container docker run -d \\ --name my-app \\ -p 3000:3000 \\ --restart unless-stopped \\ my-app:latest ``` The `--restart unless-stopped` flag ensures Docker restarts your container automatically after a server reboot or a crash. This is essential for any production deployment. ## Step 4: Use Docker Compose for Multi-Service Apps Most real applications need more than one container. A web app typically needs an application server, a database, and possibly a cache. Docker Compose lets you define all services in a single `docker-compose.yml` file: ``` version: "3.8" services: app: build: . ports: - "3000:3000" environment: - DATABASE_URL=postgres://app:secret@db:5432/myapp - REDIS_URL=redis://cache:6379 depends_on: - db - cache restart: unless-stopped db: image: postgres:16-alpine volumes: - pgdata:/var/lib/postgresql/data environment: - POSTGRES_USER=app - POSTGRES_PASSWORD=secret - POSTGRES_DB=myapp restart: unless-stopped cache: image: redis:7-alpine restart: unless-stopped volumes: pgdata: ``` Deploy everything with a single command: ``` docker compose up -d ``` Docker Compose handles networking between containers automatically. Your app reaches the database at `db:5432` and Redis at `cache:6379`—no IP addresses or host networking required. For more on composing multi-container stacks, see our guide on [deploying Docker containers to a VPS without Kubernetes](/blog/deploy-docker-containers-to-vps-without-kubernetes). ## Step 5: Set Up a Reverse Proxy with SSL Running Docker containers on raw ports is fine for testing, but production apps need HTTPS. A reverse proxy like [Nginx, Caddy, or Traefik](/blog/nginx-caddy-cloudpanel-reverse-proxy) sits in front of your containers, terminates SSL, and routes traffic by domain name. Traefik is particularly well suited for Docker VPS hosting because it auto-discovers containers and provisions Let's Encrypt certificates. Add it to your Compose file: ``` {`services: traefik: image: traefik:v3 command: - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=you@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - letsencrypt:/letsencrypt restart: unless-stopped app: build: . labels: - "traefik.enable=true" - "traefik.http.routers.app.rule=Host(\`app.yourdomain.com\`)" - "traefik.http.routers.app.entrypoints=websecure" - "traefik.http.routers.app.tls.certresolver=letsencrypt" restart: unless-stopped volumes: letsencrypt:`} ``` With this setup, Traefik automatically requests and renews SSL certificates for every domain you add. For a deeper dive into zero-downtime deployments behind Traefik, check out our [zero-downtime deployment guide](/blog/zero-downtime-deployment-traefik-vps). ## Step 6: Manage Environment Variables and Secrets Never hardcode secrets in your Docker images. Use environment variables with a `.env` file: ``` # .env DATABASE_URL=postgres://app:strongpassword@db:5432/myapp REDIS_URL=redis://cache:6379 SECRET_KEY=your-random-secret-key NODE_ENV=production ``` Reference it in your Compose file with `env_file: .env` or individual `environment` entries. Keep `.env` out of version control by adding it to `.gitignore`. Managing environment variables across multiple apps on a VPS gets tedious fast. Server Compass includes a dedicated [environment variables editor](/features/env-vars-editor) that lets you add, edit, and revoke secrets through a visual interface—no SSH session or text editor required. ## Step 7: Build a Repeatable Deployment Workflow A manual `git pull && docker compose up -d` works for side projects, but production Docker deployments need a repeatable process. Here is a basic deployment script: ``` #!/bin/bash set -e # Pull latest code cd /opt/my-app git pull origin main # Build and deploy with zero downtime docker compose build --no-cache docker compose up -d --remove-orphans # Clean up old images docker image prune -f echo "Deployment complete" ``` For teams, automate this with [GitHub Actions deploying to your VPS via SSH](/blog/self-hosted-cicd-github-actions-vps). Push to `main`, and your CI pipeline builds, tests, and deploys automatically. ### Handle Rollbacks Tag every Docker image with a version or commit hash so you can roll back quickly: ``` # Tag with git commit hash docker build -t my-app:$(git rev-parse --short HEAD) . docker tag my-app:$(git rev-parse --short HEAD) my-app:latest # Roll back to a previous version docker compose down docker tag my-app:abc1234 my-app:latest docker compose up -d ``` ## Step 8: Monitor Containers and View Logs Once your Docker apps are deployed to your VPS, you need visibility into what is running. Docker provides built-in tools for this: ``` # List running containers docker ps # View logs for a specific container docker logs -f my-app # Check resource usage docker stats ``` For production, consider deploying a monitoring stack. [Uptime Kuma](/templates/uptime-kuma) monitors HTTP endpoints, [Grafana](/templates/grafana) visualizes metrics, and [Portainer](/templates/portainer) gives you a web UI for [container management](https://1devtool.com/features/docker-containers). Server Compass bundles [container health monitoring](/features/container-status), [live log streaming](/features/container-logs), and [resource monitoring](/features/monitoring-agent) into a single desktop app. You see every container's status, uptime, and resource usage without SSHing into the server. ## Step 9: Handle Persistent Data Docker containers are ephemeral—when you remove one, its data disappears. Use named volumes for anything that needs to persist: ``` volumes: pgdata: driver: local uploads: driver: local ``` Map them in your service definitions: `volumes: - pgdata:/var/lib/postgresql/data`. Back up volumes regularly with `docker run --rm -v pgdata:/data -v $(pwd):/backup alpine tar czf /backup/pgdata.tar.gz /data`. For automated backups, Server Compass offers [encrypted cloud backups to S3-compatible storage](/blog/cloud-backup-s3-encrypted) and [full server snapshots](/blog/server-snapshots-disaster-recovery) that capture your entire Docker setup in a single file. ## Docker Production Deployment Checklist Before you consider your Docker VPS hosting setup production-ready, run through this checklist: Item Why It Matters **SSH key authentication** Prevents brute-force password attacks **Firewall (UFW)** Only expose ports 22, 80, and 443 **Non-root Docker user** Limits blast radius of container escapes **Automatic container restarts** `restart: unless-stopped` keeps services alive **SSL certificates** Traefik + Let's Encrypt for free HTTPS **Named volumes** Prevent data loss across container updates **Environment variables** Secrets stay out of images and repos **Log rotation** Docker JSON logs can fill disk without limits **Automated backups** Volumes and database dumps on a schedule **Monitoring** Know when containers crash before users do Server Compass handles most of this checklist automatically. When you [deploy through the Docker Stack Wizard](/features/docker-stack-wizard), it configures Traefik, provisions SSL, sets up restart policies, and manages environment variables—all from a visual UI. ## Skip the Manual Work with Server Compass The steps above work, but they involve a lot of terminal sessions, YAML editing, and manual server administration. Every new app means repeating the same setup: Compose file, Traefik labels, environment variables, domain config. ![Server Compass app dashboard showing multiple Docker apps running on a VPS](/app-screenshots/feature-app-dashboard.jpg) [Server Compass](https://servercompass.app) is a desktop app that replaces this entire manual workflow with a visual interface. Connect your VPS, pick a [deployment template](/features/template-deployment) or point it at your GitHub repo, configure your environment variables, and deploy. Docker installation, Traefik configuration, SSL certificates, and container management all happen behind the scenes. What takes 30 minutes of terminal work takes about 2 minutes in Server Compass. You still own your VPS, you still run standard Docker containers, and you can SSH in anytime to inspect things manually. The difference is you do not have to. Whether you deploy Docker apps to a VPS the manual way or use a tool to simplify the process, the fundamentals are the same: SSH access, Docker Engine, Compose for multi-service apps, and a reverse proxy for SSL. Master these building blocks and you can host anything on any VPS provider—no platform lock-in, no surprise bills, just containers on a server you control. Ready to simplify your Docker VPS hosting? [Try Server Compass](https://servercompass.app) and deploy your first app in minutes, or explore our [template gallery](/templates) with 200+ one-click Docker deployments. --- **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'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. --- ## How to Turn a VPS Into Your Own Vercel Source: https://servercompass.app/blog/turn-vps-into-your-own-vercel Published: 2026-04-05 Tags: vercel-alternative, self-hosted, deployment, docker, vps-deploy, coolify Replicate Vercel's key features — git push deployments, auto-SSL, preview environments, and zero-downtime deploys — on a $5/month VPS. Compare tools like Coolify and see why Server Compass is the fastest path to a self-hosted Vercel experience. Vercel is brilliant. You connect a GitHub repo, push code, and your app is live with SSL, preview URLs, and zero-downtime deploys. For solo developers on the free tier, it's hard to beat. But the moment your team grows or your traffic spikes, the bills start adding up fast — $20/seat/month on Pro, bandwidth overages, and serverless function limits that punish success. The good news: every feature that makes Vercel feel magical can be replicated on a $5/month VPS. You keep full control, pay predictable costs, and never worry about vendor lock-in. This guide shows you exactly how to build a **self-hosted Vercel** experience on your own infrastructure. ## What Makes Vercel Great (And What We Need to Replicate) Before we start building, let's identify the four features that define the Vercel experience: 1. **Git push deployments** — push to `main` and your app deploys automatically 2. **Automatic SSL** — every domain gets HTTPS with zero configuration 3. **Preview environments** — every pull request gets its own URL for review 4. **Zero-downtime deploys** — updates go live without dropping a single request Each of these is achievable on a VPS. The question is whether you want to wire it all together yourself or use a tool that handles it for you. ## The Cost Math: Vercel vs a VPS Let's do the math before we get into implementation. This is where the **vercel alternative vps** argument becomes compelling. Scenario Vercel Pro VPS + Server Compass Solo developer $20/month $5/month VPS + $29 one-time Team of 3 $60/month $5/month VPS + $29 one-time Team of 5 $100/month $10/month VPS + $29 one-time Annual cost (team of 3) $720/year $60/year + $29 once That's not a typo. A team of three on Vercel Pro pays **$720/year**. The same team on a VPS pays **$89 in year one** and **$60/year after that**. And unlike Vercel, your VPS can host unlimited projects, databases, and services — not just frontend apps. For a deeper breakdown, see our [Vercel pricing analysis](/blog/vercel-pricing-explained-hidden-costs). ## Feature 1: Git Push Deployments The cornerstone of the Vercel workflow is pushing code and having it deploy automatically. Here's how to get the same thing on your VPS. ### The DIY Approach You can set up git push deployments with a combination of GitHub Actions (or any CI) and SSH: ``` # .github/workflows/deploy.yml name: Deploy to VPS on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Build Docker image run: docker build -t myapp . - name: Push to registry run: | echo $\{{ secrets.GHCR_TOKEN }} | docker login ghcr.io -u $\{{ github.actor }} --password-stdin docker tag myapp ghcr.io/$\{{ github.repository }}:latest docker push ghcr.io/$\{{ github.repository }}:latest - name: Deploy via SSH uses: appleboy/ssh-action@v1 with: host: $\{{ secrets.VPS_HOST }} username: root key: $\{{ secrets.VPS_SSH_KEY }} script: | docker pull ghcr.io/$\{{ github.repository }}:latest docker compose up -d ``` This works, but there's a lot of boilerplate. You need to manage SSH keys as secrets, handle Docker registry authentication, and write the deployment logic yourself. Every new project needs a copy of this workflow file. ### The Server Compass Approach With Server Compass, you [connect your GitHub account](/features/github-repo-deploy) once and select a repository. Server Compass handles the rest — cloning, building, deploying, and switching traffic. Enable [auto-deploy on push](/features/auto-deploy) and every commit to your target branch triggers a new deployment automatically. You can also use [GitHub Actions integration](/features/github-actions) to build on GitHub's free CI minutes and deploy the resulting image to your VPS, keeping your server resources free for running apps instead of building them. ![Server Compass GitHub deployment interface showing repository selection and branch configuration](/app-screenshots/feature-github-deploy.jpg) ## Feature 2: Automatic SSL Certificates Vercel gives every deployment HTTPS by default. On a VPS, you need a reverse proxy that handles TLS termination and certificate renewal. ### The DIY Approach: Traefik or Caddy **Traefik** is the standard choice for Docker-based deployments. It watches for new containers, reads labels for routing configuration, and automatically provisions Let's Encrypt certificates: ``` {`# docker-compose.yml (Traefik setup) services: traefik: image: traefik:v3 command: - "--providers.docker=true" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.le.acme.tlschallenge=true" - "--certificatesresolvers.le.acme.email=you@example.com" ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock - letsencrypt:/letsencrypt myapp: image: myapp:latest labels: - "traefik.enable=true" - "traefik.http.routers.myapp.rule=Host(\`app.example.com\`)" - "traefik.http.routers.myapp.tls.certresolver=le"`} ``` **Caddy** is another option that handles HTTPS automatically with even less configuration. If you already run Nginx or Caddy, check our guide on [using your existing reverse proxy with Server Compass](/blog/nginx-caddy-cloudpanel-reverse-proxy). ### The Server Compass Approach Server Compass installs and configures Traefik automatically when you connect your first server. Add a domain to any app, and [SSL certificates](/features/auto-ssl) are provisioned within seconds. Renewal is automatic. You also get [DNS verification](/features/dns-verification), a [certificate viewer](/features/certificate-viewer), [WWW redirect](/features/www-redirect) toggles, and [per-domain security headers](/features/domain-security) — all through a visual interface, not YAML files. ## Feature 3: Preview Environments Preview environments are one of Vercel's most loved features. Every pull request gets a unique URL where reviewers can see the changes live before merging. ### The DIY Approach Building preview environments yourself requires significant orchestration: 1. Listen for GitHub PR webhooks 2. Build a Docker image for the PR branch 3. Deploy it on a unique subdomain (e.g., `pr-42.preview.example.com`) 4. Provision an SSL certificate for the subdomain 5. Post the preview URL as a comment on the PR 6. Clean up the container and domain when the PR is closed This is doable with GitHub Actions plus some scripting, but it's a maintenance burden that grows with every project. ### The Server Compass Approach Server Compass has built-in [staging and preview environments](/features/preview-environments). Create a preview environment for any branch, and it gets its own domain, its own SSL certificate, and its own environment variables. Set an auto-delete timer so preview environments clean themselves up after a configurable number of days. When you're happy with the preview, promote it to production with one click. See our detailed walkthrough in [the preview environments blog post](/blog/staging-preview-environments-activity-logs). ## Feature 4: Zero-Downtime Deployments Vercel deploys are instant because they use an immutable deployment model — the new version is built and ready before traffic switches to it. Your VPS can do the same thing. ### The DIY Approach Zero-downtime deployments on a VPS require a blue-green or rolling update strategy: ``` # Basic blue-green deploy script NEW_CONTAINER=$(docker run -d myapp:new) # Wait for health check until curl -sf http://localhost:NEW_PORT/health; do sleep 1 done # Update Traefik routing labels docker label $NEW_CONTAINER traefik.enable=true docker stop $OLD_CONTAINER docker rm $OLD_CONTAINER ``` In practice, this is more complex than it looks. You need health check logic, timeout handling, automatic rollback on failure, and coordination with Traefik's routing. Most teams end up writing 200+ lines of bash to handle edge cases. ### The Server Compass Approach [Zero-downtime deployment](/features/zero-downtime) is a toggle in Server Compass. Enable it globally or per-app. The new container builds in the background while the old one keeps serving traffic. Health checks verify the new version is ready. Traefik switches traffic atomically — not a single request is dropped. If the new container fails, the old one keeps running and you get a clear error message. Read the full breakdown in our [zero-downtime deployment deep dive](/blog/zero-downtime-deployment-traefik-vps). ![Server Compass zero-downtime deployment interface with health check status and deployment history](/app-screenshots/feature-auto-deploy.jpg) ## Bonus: What You Get on a VPS That Vercel Doesn't Give You A self-hosted Vercel setup on your own VPS isn't just about replicating features — it's about gaining capabilities Vercel doesn't offer: - **Run any stack** — not just Next.js and React. Deploy [Laravel](/install/laravel), [Django](/install/django), [Rails](/install/rails), [FastAPI](/install/fastapi), or any Docker container - **Host databases alongside your apps** — [PostgreSQL](/templates/postgresql), [MySQL](/templates/mysql), [Redis](/templates/redis), and [MongoDB](/templates/mongodb) on the same server with no add-on fees - **Run background workers and cron jobs** — no serverless function timeouts or edge runtime limitations - **Full SSH access** — debug production issues directly instead of reading function logs - **One-click templates** — deploy [n8n](/templates/n8n), [Ghost](/templates/ghost), [Plausible Analytics](/templates/plausible), and 200+ other self-hosted tools alongside your main app ## Tool Comparison: Coolify vs Server Compass If you're searching for a **self-hosted Vercel** solution, two tools come up most often: **Coolify** and **Server Compass**. Both aim to give you PaaS-like convenience on your own VPS, but they take different approaches. Feature Coolify Server Compass Architecture Self-hosted web panel (runs on your VPS) Desktop app (connects via SSH) Setup time 10-20 minutes (install script + configuration) 2 minutes (download + connect) Server overhead Uses 500MB-1GB RAM on your VPS Zero overhead (runs on your computer) Git push deploys Yes (webhook-based) Yes (GitHub integration + auto-deploy) Auto-SSL Yes (Traefik or Caddy) Yes (Traefik) Preview environments Yes Yes (with auto-delete timer) Zero-downtime deploys Yes Yes (with health checks + automatic rollback) One-click templates 60+ services 200+ templates Pricing Free (self-hosted) or $5/month (cloud) $29 one-time license Coolify is a solid open-source option, especially if you prefer a web-based interface. However, it requires installation on your VPS and consumes resources that could be running your apps. For a more detailed comparison, see our [Coolify vs Server Compass](/compare/coolify) analysis and our [in-depth comparison blog post](/blog/server-compass-vs-coolify-best-self-hosted-deployment-tools-in-2025). Server Compass takes a different approach — it's a desktop application that connects to your VPS over SSH. Nothing is installed on your server except Docker and Traefik (which you'd need anyway). This means zero RAM overhead, zero attack surface on the server, and you can manage multiple VPS instances from one place. ## Getting Started: VPS to Vercel in 15 Minutes Here's the fastest path to a self-hosted Vercel experience with Server Compass: ### Step 1: Get a VPS ($5/month) Any Linux VPS with 1GB+ RAM works. Popular choices: Hetzner (best value in Europe), DigitalOcean, Linode, or Vultr. Ubuntu 22.04 or 24.04 is recommended. ### Step 2: Download Server Compass and Connect [Download Server Compass](/), enter your server IP and SSH credentials, and connect. Server Compass installs Docker and Traefik automatically on first connection. Our [connection tutorial](/tutorials/connect-server-password) walks you through this in 30 seconds. ### Step 3: Connect Your GitHub Account Link your GitHub account in the settings. This gives Server Compass access to your repositories for one-click deployment. See the [GitHub connection tutorial](/tutorials/how-to-connect-your-github-account-and-deploy-your-first-nextjs-app-to-your-vps) for a full walkthrough. ### Step 4: Deploy Your First App Select a repository, pick a branch, and hit deploy. Server Compass detects your framework — whether it's [Next.js](/install/nextjs), [Nuxt](/install/nuxtjs), [SvelteKit](/install/sveltekit), [Remix](/install/remix), or any Dockerized app — and builds it with the right configuration. Add a domain, and SSL is provisioned automatically. ### Step 5: Enable Auto-Deploy and Zero-Downtime Toggle auto-deploy on push and enable zero-downtime deployment. Now every `git push` to your target branch triggers an automatic deployment with no downtime. You've just replicated Vercel's core workflow. ## What About Edge Functions and CDN? There are two Vercel features a single VPS can't replicate: edge functions running in 30+ regions and a global CDN. If your app needs sub-50ms response times worldwide, Vercel or Cloudflare Workers is the right choice. But most apps don't need that. If your users are primarily in one region (which is true for the vast majority of SaaS products, internal tools, and side projects), a VPS in that region with a Cloudflare free-tier CDN in front of it gives you comparable performance at a fraction of the cost. ## Who Should Make the Switch? A **vercel self hosted** approach makes sense if you: - Run a team and want to avoid per-seat pricing - Need databases, cron jobs, or background workers alongside your frontend - Want predictable costs that don't scale with traffic - Prefer to own your infrastructure and avoid vendor lock-in - Deploy apps in frameworks other than Next.js (Laravel, Django, Rails, Go, etc.) - Run multiple projects and want them all on one server Stick with Vercel if you're a solo developer on the free tier, need edge functions for a latency-sensitive consumer app, or simply don't want to manage a server at all. ## From Platform to Infrastructure Vercel popularized a workflow that developers love: push code, get a URL. That workflow doesn't require Vercel. With the right tools, a $5/month VPS gives you the same git push deployments, auto-SSL, preview environments, and zero-downtime deploys — plus the freedom to run anything Docker can run. Server Compass is the fastest way to get there. One $29 license, no per-seat fees, no bandwidth limits. Connect your VPS, connect your GitHub, and deploy. It's everything Vercel does, on infrastructure you own. [Try Server Compass](/) and turn your VPS into your own Vercel today. Or read our [full Vercel comparison](/compare/vercel) to see every feature side by side. --- **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. --- ## Reclaim Disk Space and Lock Your Production Servers Source: https://servercompass.app/blog/disk-management-lock-server-vps Published: 2026-04-01 Tags: docker, disk-management, security, server-management, self-hosted Scan your VPS for reclaimable disk space with a visual breakdown by category, clean up with one click, and lock production servers into read-only mode to prevent accidental changes. Your VPS started with 50GB of disk space. Six months later, you're at 90% usage and don't know why. Is it Docker images? Build cache? Old log files? Orphaned volumes? Finding and cleaning up wasted space usually means SSH-ing in and running a series of `docker system df`, `docker image prune`, and `du -sh` commands. Server Compass v1.20.1 adds a visual disk management scanner that shows you exactly where your space is going and lets you reclaim it with one click. ## Server-Wide Disk Scanner The disk management panel scans your entire VPS and breaks down usage across categories: - **Docker images** — current images and their sizes - **Build cache** — accumulated from Docker builds - **Dangling volumes** — orphaned data from deleted containers - **Stopped containers** — containers that exited but weren't removed - **System logs** — journald and other log files - **App folders** — source code and build artifacts per app ## One-Click Cleanup Select any category and clean it individually, or select multiple categories and clean them all at once. Real-time progress shows you exactly what's being removed and how much space you're reclaiming. No more guessing what `docker system prune -a` will actually delete. ## Per-App Disk Usage Each app's Overview tab now shows how much disk space its images, volumes, containers, and app folder are consuming. Find the app that's eating all your storage and prune its dangling images directly from the overview page. ## Lock Server: Read-Only Mode for Production Ever accidentally deployed to production when you meant to deploy to staging? Lock Server prevents this entirely. Toggle a server into read-only mode from Server Settings, and Server Compass blocks all destructive actions: - Deploy, redeploy, and delete are disabled - Start, stop, and restart are blocked - A lock icon appears in the sidebar so you know at a glance which servers are protected When you need to deploy, unlock the server, make your changes, and lock it again. Simple, reversible, and prevents the scariest category of accidental operations. ## Selective Backup When exporting or uploading backups, you can now choose which servers to include instead of backing up everything. Only back up the servers that changed, or exclude development servers from your production backup. ## Download Terminal Logs Save terminal session output as a timestamped `.txt` file. Useful for auditing, sharing debug output with teammates, or keeping records of maintenance sessions. ## Before vs After Task Before After Find what's using disk space `docker system df` + `du -sh /*` Visual breakdown by category Clean Docker build cache `docker builder prune` Click "Clean" next to Build Cache Prevent accidental prod deploy Be careful Lock the server Back up specific servers All or nothing Checkbox per server ## Take Control of Your Disk Space Stop guessing where your storage went. [Try Server Compass](https://servercompass.app) and reclaim disk space with one click. --- **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. --- ## Deploy from Docker Hub, GHCR, or Any Registry — No Build Step Required Source: https://servercompass.app/blog/docker-registry-deploy-trust-proxy Published: 2026-03-29 Tags: docker, deployment, cloudflare, traefik, self-hosted Deploy pre-built container images from Docker Hub, GHCR, or private registries to your VPS without a build step. Plus configure trusted proxy headers for real visitor IPs behind Cloudflare. Not every deployment starts from source code. Maybe your team builds images in CI and pushes them to a registry. Maybe you want to deploy a third-party image that doesn't have a Server Compass template. Either way, you shouldn't need to build on the server. Server Compass v1.20.0 adds Pull from Registry—deploy any pre-built container image from Docker Hub, GitHub Container Registry (GHCR), or private registries directly to your VPS. No source code, no build step, no Dockerfile. ## Pull from Registry ### Search and Verify Images Enter any image reference (`nginx:latest`, `ghcr.io/your-org/your-app:v2`) and Server Compass verifies it exists before deploying. No more deploying a typo and waiting for a pull failure. ### Auto-Detect Ports Server Compass knows the default ports for 30+ popular images—Nginx (80), PostgreSQL (5432), Redis (6379), and many more. For custom images, it reads exposed ports from the image metadata and pre-fills them automatically. ### Port Conflict Detection Before deploying, see which ports are already in use on your server. Server Compass warns you about conflicts and suggests alternatives so deployments don't fail at startup. ### Public and Private Registry Support Docker Hub and GHCR work out of the box. For private registries, authenticate with GitHub credentials or saved registry tokens. Server Compass includes setup guides for Docker Hub, GHCR, GitLab Container Registry, Google Cloud Artifact Registry, AWS ECR, and custom registries. ### One-Click Redeploy Pushed a new image tag? Click Redeploy to pull the latest version and restart with no extra steps. Every deployment records which image and tag was deployed, so you can track exactly what's running. ## Trust Proxy Headers If your VPS sits behind Cloudflare, AWS ALB, DigitalOcean, or Hetzner load balancers, your apps see the proxy's IP address instead of the real visitor's IP. This breaks rate limiting, geo-targeting, and audit logs. The new Trust Proxy Headers feature configures Traefik to trust forwarded headers from your proxy provider: - **One-click Cloudflare preset** — all Cloudflare IPv4 and IPv6 ranges pre-filled - **Cloud provider presets** — AWS ALB, DigitalOcean, and Hetzner load balancers - **Custom IP lists** — add any trusted IP ranges manually - **Safe updates with auto-rollback** — Traefik config is backed up before changes, automatically restored if Traefik fails to start ## Deploy Any Image Pull from Registry is now a top-level option in the Stack Wizard alongside GitHub, Upload, and Local Build. [Try Server Compass](https://servercompass.app) and deploy pre-built images to your VPS in seconds. --- **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. --- ## Deploy NocoDB with Docker on Ubuntu on Hetzner Cloud Source: https://servercompass.app/blog/deploy-nocodb-docker Published: 2026-03-26 Tags: nocodb, docker, ubuntu, hetzner, self-hosted, tutorial Learn how to deploy NocoDB, a self-hosted Airtable alternative, on a Hetzner Cloud server with Docker Compose, PostgreSQL, and a firewall. ## Introduction NocoDB is an open-source Airtable alternative that lets you turn an existing database into a spreadsheet-style interface. It supports REST APIs, team collaboration, and connections to MySQL or PostgreSQL. In this tutorial, you will deploy NocoDB on a Hetzner Cloud server using Docker. For users who prefer GUI tools, applications such as [Server Compass](/) can automate parts of this process. However, this guide walks through the deployment step by step rather than hiding it behind a GUI. NocoDB requires relatively little memory (around 256 MB), so even small Hetzner Cloud servers can run it comfortably. On a small Hetzner Cloud server, the whole deployment usually takes only a few minutes. **Prerequisites** - A [Hetzner Cloud](https://console.hetzner.cloud/) account - A server running Ubuntu 24.04 - SSH access to the server - (Optional) A graphical server management tool such as [Server Compass](/), which offers a free tier supporting a single server and application ## Overview In this tutorial, you will: - Create a Hetzner Cloud server running Ubuntu 24.04 - Configure SSH access to the server - Install Docker on the server - Deploy NocoDB using Docker Compose - Verify the deployment and access the NocoDB web interface ## Step 1 - Generate an SSH Key An SSH key lets your computer connect securely to a remote server without a password. You can generate one using the following command: ``` ssh-keygen -t ed25519 -C "nocodb-server" ``` This saves a key pair to `~/.ssh/`. To view your public key, run: ``` cat ~/.ssh/id_ed25519.pub ``` Copy the output and paste it into the SSH key field in the Hetzner Cloud Console in the next step. If you prefer a graphical approach, tools such as Server Compass include a built-in key generator. ### Using Server Compass (Optional) 1. Open Server Compass 2. Click **SSH Keys** in the left sidebar 3. Click **\+ Generate New Key** in the top right ![Generate SSH key in Server Compass](/blogs/deploy-nocodb-docker/images/1-generate-ssh-key.jpg) 4. Enter a name for your key (for example: `my-demo-vps`) 5. Click **Generate Key Pair** ![Name your SSH key](/blogs/deploy-nocodb-docker/images/2-name-your-ssh-key.jpg) Server Compass generates a key pair and saves it on your computer. 6. Find your new key in the list and click **Public Key** to copy it to your clipboard ![Copy public key in Server Compass](/blogs/deploy-nocodb-docker/images/4-how-to-copy-publickey-in-server-compass.jpg) ## Step 2 - Create a Hetzner Cloud Server Log into the [Hetzner Cloud Console](https://console.hetzner.cloud/) and create a server that will run NocoDB. 1. Select your project (or create a new one by clicking **\+ New Project**) 2. Click **Add Server** 3. Choose a **Location** closest to your users 4. Choose **Ubuntu 24.04** as the image 5. Choose the **CPX12** server type (1 vCPU, 2 GB RAM) — the cheapest option works fine since NocoDB only needs 256 MB of RAM ![CPX12 server type selection](/blogs/deploy-nocodb-docker/images/cpx12.jpg) 6. In the **SSH Keys** section, click **\+ Add SSH key** ![Add SSH key in Hetzner Cloud Console](/blogs/deploy-nocodb-docker/images/3-add-ssh-key-in-hetzer.jpg) 7. Paste the public key you generated in Step 1 8. Enter a name (for example: `my-demo-vps`) 9. Click **Add SSH key** ![Paste SSH key in Hetzner Cloud Console](/blogs/deploy-nocodb-docker/images/5-paste-key-in-hetzer.jpg) 10. Set the server name to `my-demo-production` 11. Click **Create & Buy Now** Your server will be ready in about 30 seconds. Note the **IPv4 address** displayed — you will need it in the following steps. ## Step 3 - Connect to Your Server ### Using the terminal Connect to your server using SSH: ``` ssh root@ ``` Replace `` with the IPv4 address from Step 2. ### Using Server Compass (Optional) 1. In Server Compass, click **Add Server** ![Add Server button in Server Compass](/blogs/deploy-nocodb-docker/images/6-add-server-button-press.jpg) 2. In the next screen, select `I know how to connect VPS before` ![Select already has VPS option](/blogs/deploy-nocodb-docker/images/select-already-has-vps.jpg) 3. Fill in the following details: Field Value Display Name `my-demo-vps` Server IP / Hostname Your server's IPv4 address from Step 2 Username `root` Port `22` 4. Under **Choose your authentication method**, select **SSH Key** 5. Select the key you created in Step 1 from the dropdown 6. Click **Test & Connect** ![Server Compass connection settings](/blogs/deploy-nocodb-docker/images/connect-server-fill-in-fields.jpg) ## Step 4 - Install Docker Install Docker and Docker Compose on the server. Update and upgrade the package lists: ``` apt update && apt upgrade -y ``` Install Docker: ``` apt install docker.io docker-compose-plugin -y ``` Enable Docker to start automatically on boot: ``` systemctl enable docker systemctl start docker ``` Verify the installation: ``` docker --version ``` You should see output similar to `Docker version 24.x.x`. ## Step 5 - Deploy NocoDB with Docker ### Configure a Firewall Enable a firewall to restrict open ports: ``` ufw allow OpenSSH ufw allow 8080 ufw enable ``` This allows SSH access and the NocoDB web interface while blocking other incoming connections. ### Deploy Using Docker Compose Create a directory for NocoDB and navigate into it: ``` mkdir -p ~/apps/nocodb && cd ~/apps/nocodb ``` Create a `docker-compose.yml` file: ``` nano docker-compose.yml ``` Paste the following configuration: > **Note:** The passwords shown below are for demonstration purposes only. For production environments, replace them with secure randomly generated values before deploying. ``` services: nocodb: image: nocodb/nocodb:latest ports: - "8080:8080" environment: - NC_DB=pg://db:5432?u=nocodb&p=CHANGE_THIS_PASSWORD&d=nocodb - NC_AUTH_JWT_SECRET=CHANGE_THIS_SECRET - NC_PUBLIC_URL=http://:8080 - NC_DISABLE_TELE=false volumes: - nocodb_data:/usr/app/data restart: unless-stopped depends_on: db: condition: service_healthy db: image: postgres:16-alpine environment: - POSTGRES_DB=nocodb - POSTGRES_USER=nocodb - POSTGRES_PASSWORD=CHANGE_THIS_PASSWORD volumes: - db_data:/var/lib/postgresql/data restart: unless-stopped healthcheck: test: ["CMD-SHELL", "pg_isready -U nocodb -d nocodb"] interval: 10s timeout: 5s retries: 5 start_period: 30s volumes: nocodb_data: db_data: ``` Replace `` with your actual server IPv4 address, and both instances of `CHANGE_THIS_PASSWORD` and `CHANGE_THIS_SECRET` with secure values. Save the file (`Ctrl+O`, then `Enter`, then `Ctrl+X`), then start the containers: ``` docker compose up -d ``` Docker will pull the NocoDB and PostgreSQL images and start both containers in the background. ### Deploy Using Server Compass (Optional) Server Compass can automate the same deployment using a preconfigured NocoDB template. 1. Click on your server to open its detail page 2. Click the **Apps** tab 3. Click **\+ New App** in the top right ![Click New App in Server Compass](/blogs/deploy-nocodb-docker/images/1-add-new-app.jpg) 4. Select **App Template** ![Select App Template](/blogs/deploy-nocodb-docker/images/2-select-template.jpg) 5. Search for `nocodb` and select the **NocoDB** template, then click **Next** ![Search for NocoDB template](/blogs/deploy-nocodb-docker/images/3-search-for-nocodb-template.jpg) 6. Enter a **Project Name** (e.g., `nocodb`) and keep the default port `8080`, then click **Next** ![Configure project name and port](/blogs/deploy-nocodb-docker/images/4-fill-appname-name-port.jpg) 7. Review the environment variables, then click **Deploy** ![Review and deploy configuration](/blogs/deploy-nocodb-docker/images/5-configure-env-like-dbname-password-or-use-default.jpg) Server Compass will pull the Docker images, configure the containers, and start the application. ![NocoDB deployment in progress](/blogs/deploy-nocodb-docker/images/6-deployment-progress-loading.jpg) ## Step 6 - Verify the Deployment Verify that the NocoDB containers are running: ``` docker ps ``` You should see output similar to: ``` CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES fe105f3ec178 nocodb/nocodb:latest "/usr/bin/dumb-init …" About an hour ago Up About an hour 0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp nocodb-nocodb-1 789a818a5e36 postgres:16-alpine "docker-entrypoint.s…" About an hour ago Up About an hour (healthy) 5432/tcp nocodb-db-1 ``` Both containers should show an `Up` status. > **Note:** On a fresh server, the PostgreSQL container usually needs around 20–40 seconds to pass its health check before NocoDB starts responding. If the NocoDB container shows `starting` rather than `Up`, wait a moment and run `docker ps` again. ## Step 7 - Access NocoDB Open your browser and navigate to: ``` http://:8080 ``` Replace `` with your server's actual IPv4 address from Step 2. You will see the NocoDB sign-up page. Create your admin account to get started. ![NocoDB sign-up page](/blogs/deploy-nocodb-docker/images/nocodb-signup.jpg) After signing in, you are ready to create your first table in NocoDB. ![NocoDB dashboard](/blogs/deploy-nocodb-docker/images/first_table.jpg) > **Note:** Accessing the application through an IP address is fine for testing. For production deployments, it is recommended to configure a domain and HTTPS using a reverse proxy such as Nginx, Traefik, or Caddy. ## Troubleshooting If you cannot access the NocoDB interface, check the following: **Container status** Run `docker ps` to check if both containers are running. If a container is missing, inspect the logs: ``` docker compose logs nocodb ``` **Port access** Confirm that port 8080 is allowed by your firewall: ``` ufw status ``` If port 8080 is not listed, add it: ``` ufw allow 8080 ``` **Server IP address** Verify you are using the correct IPv4 address from the Hetzner Cloud Console. IPv6 addresses will not work unless NocoDB is specifically configured for them. **Container startup time** The PostgreSQL container runs a health check before NocoDB starts. Wait 30–60 seconds after running `docker compose up -d` before accessing the interface. ## Conclusion NocoDB is now running on your server and ready to use. Because the application runs in Docker containers, updating or restarting it later is as simple as running `docker compose pull` and `docker compose up`. ``` docker compose pull && docker compose up -d ``` **Next steps:** - Configure a domain name and HTTPS using a reverse proxy - Create your first NocoDB project - Configure backups for the PostgreSQL volume --- **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. --- ## 50 New One-Click Deploy Templates: From AI Tools to Media Servers Source: https://servercompass.app/blog/50-one-click-deploy-templates-self-hosted Published: 2026-03-24 Tags: templates, self-hosted, docker, deployment, homelab Deploy 50 new self-hosted apps including AnythingLLM, Plex, Affine, Dashy, and Pi-hole with one click. Server Compass now ships 247 templates total. Self-hosting an app should be as easy as clicking "Install" on the App Store. But most self-hosted apps require reading Docker Compose documentation, configuring environment variables, and figuring out port mappings. Every app has its own setup quirks. Server Compass v1.19.0 adds 50 new one-click deploy templates, bringing the total to 247. Pick an app, click Deploy, and it's running on your VPS with all the correct configuration pre-filled. ## AI & Machine Learning (11 templates) Self-host your AI stack: **AnythingLLM** (RAG chat with any document), **Flowise** (visual LLM workflow builder), **Langflow** (LangChain UI), **Chroma** and **Qdrant** (vector databases), **LiteLLM** (unified LLM proxy), **Label Studio** (data labeling), **Argilla** (LLM evaluation), **MindsDB** (AI-in-database), **Mage AI** (ML pipelines), and **Unstructured** (document parsing). ## Media & Entertainment (9 templates) Build your own streaming platform: **Plex** and **Emby** (video), **Audiobookshelf** (audiobooks/podcasts), **Navidrome** (music), **Ente Photos** (Google Photos alternative), plus the \*arr stack: **Sonarr**, **Radarr**, **Prowlarr**, and **Overseerr** for automated media management. ## Productivity & Notes (8 templates) Replace your SaaS subscriptions: **Affine** (Notion alternative), **AppFlowy** (Notion alternative), **Docmost** (team wiki), **Joplin** (note-taking), **SiYuan** (knowledge base), **TriliumNext** (hierarchical notes), **Vikunja** (task manager), and **Teable** (Airtable alternative). ## Dev Tools (6 templates) **Code Server** (VS Code in the browser), **PgAdmin**, **CloudBeaver** (web database manager), **Jupyter Notebook**, and **GitHub Runner** (self-hosted CI). ## Dashboards (4 templates) **Dashy**, **Homarr**, **Homepage**, and **Heimdall** with Docker auto-discovery. See all your self-hosted services on one page. ## Infrastructure & Networking (6 templates) **RabbitMQ** (message broker), **Mosquitto** (MQTT), **Cloudflared** (Cloudflare Tunnel), **Pi-hole** (DNS ad-blocker), **SFTPGo** (SFTP server), and **FileBrowser** (web file manager). ## Other Popular Apps (8 templates) **Matrix Synapse** (decentralized chat), **Home Assistant** (smart home), **FreshRSS** and **Miniflux** (RSS readers), **Moodle** and **MediaWiki** (education), and **Documenso** (DocuSign alternative). ## 247 Apps, One Click Each Browse all [247 templates](/templates) in the Stack Wizard. Every template includes pre-configured environment variables, correct port mappings, and Docker volume persistence. [Try Server Compass](https://servercompass.app) and build your self-hosted stack. --- **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. --- ## Use Your Existing Nginx or Caddy Reverse Proxy with Server Compass Source: https://servercompass.app/blog/nginx-caddy-cloudpanel-reverse-proxy Published: 2026-03-22 Tags: nginx, caddy, traefik, reverse-proxy, deployment, self-hosted Keep your existing Nginx, Caddy, or CloudPanel reverse proxy while using Server Compass for Docker app deployment. Auto-detection, config generation, and one-click CloudPanel migration. You already have Nginx running on your server. You've spent time configuring it, your sites are working, and you don't want to rip it out just to try a new deployment tool. Until now, Server Compass required Traefik as the reverse proxy—which meant replacing whatever you already had. Server Compass v1.18.3 introduces multi-reverse-proxy support. Keep your existing Nginx, Caddy, or CloudPanel setup and use Server Compass purely for app deployment and management. ## Three Proxy Modes ### Managed (Traefik) The default. Server Compass installs and manages Traefik, handles SSL certificates, and configures routing automatically. Best for new servers or when you want a fully managed experience. ### External Proxy (Nginx / Caddy / CloudPanel) Use your existing reverse proxy. Server Compass deploys Docker containers and generates the proxy configuration files for you. It can even apply them automatically via SSH—creating vhosts, generating config snippets, and reloading your proxy. ### None No reverse proxy. Apps are accessible directly on their container ports. Useful for internal services, API servers behind a load balancer, or development environments. ## Auto-Detection on Connect When you connect a new server, Server Compass detects which reverse proxy is already running—Nginx, Caddy, CloudPanel, or nothing—and suggests the right mode. No guesswork. ## CloudPanel Integration If you're using CloudPanel, Server Compass goes further: - **View all CloudPanel sites** in the Server Compass interface - **Connect domains to Docker apps** managed by Server Compass - **Install Let's Encrypt SSL** through CloudPanel's certificate manager - **One-click migration to Traefik** — if you decide to switch, Server Compass moves all domains automatically ## Auto-Generated Proxy Configurations When using External Proxy mode, Server Compass generates ready-to-use configuration snippets for your proxy. For Nginx, it creates a complete server block. For Caddy, a Caddyfile entry. These are auto-applied via SSH when possible, or displayed for you to copy and paste. ## SSH Command Log Filtering Also in this release: the SSH command history now supports time range filtering. Narrow down to commands from the last hour, today, or any custom date range to find exactly what you're looking for. ## Keep What Works You don't need to change your reverse proxy to use Server Compass. [Try Server Compass](https://servercompass.app) and deploy Docker apps alongside your existing Nginx, Caddy, or CloudPanel setup. --- **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. --- ## Stop Googling Database Commands: Auto-Generate CLI and cURL in One Click Source: https://servercompass.app/blog/stop-googling-database-commands Published: 2026-03-13 Tags: database, features, tools, self-hosted, deployment Tired of searching for the right MySQL, PostgreSQL, or MongoDB command syntax? Server Compass auto-detects your database and generates ready-to-use CLI commands and cURL requests instantly. We've all been there. You deploy a database to your VPS, and now you need to run a quick query. What's the exact syntax for `mysql` again? How do you pass credentials to `psql`? What's the cURL command for ClickHouse's HTTP interface? You open a browser tab, type "mysql connect command line with password," scroll past Stack Overflow answers from 2014, and finally piece together the right incantation. Multiply this by every database you manage, and you've lost hours of your life to syntax lookup. The [Database Commands](/features/database-commands) feature in Server Compass eliminates this friction entirely. It auto-detects your database type, extracts connection credentials from your container's environment variables, and generates ready-to-run commands—all with a single click. ## The Problem: Context Switching Kills Productivity Database administration involves constant context switching. You're debugging an issue, you need to check the table structure, and suddenly you're hunting for the right CLI syntax instead of solving the actual problem. Consider what happens when you deploy a [PostgreSQL database](/templates/postgresql) to your VPS: - You need to remember that PostgreSQL uses `psql`, not `postgres` - The connection flags are different from MySQL (`-h`, `-p`, `-U`, `-d`) - Password handling requires `PGPASSWORD` environment variable or `.pgpass` file - Some commands use backslash shortcuts (`\dt`, `\d tablename`), others use SQL Now multiply this by the databases you actually use: MySQL for your WordPress sites, MongoDB for your Node.js apps, Redis for caching, ClickHouse for analytics. Each has its own CLI tool, its own syntax, its own quirks. ## How Database Commands Works When you click on a database container in Server Compass, the Database Commands modal analyzes your deployment and handles everything automatically. ![Database Commands modal showing MySQL commands with connection info auto-filled](/app-screenshots/feature-database-commands.jpg) ### Step 1: Auto-Detection Server Compass examines your container image and service name to identify the database type. It recognizes over 20 database types including: Category Supported Databases SQL MySQL, MariaDB, PostgreSQL, MSSQL PostgreSQL Extensions TimescaleDB, Hydra, Neon Document MongoDB, FerretDB, CouchDB Key-Value Redis, Valkey, KeyDB Analytics ClickHouse, Elasticsearch, OpenSearch Time-Series InfluxDB Streaming Kafka ### Step 2: Credential Extraction The feature reads your container's environment variables and extracts connection credentials. It knows that MySQL uses `MYSQL_ROOT_PASSWORD` while PostgreSQL uses `POSTGRES_PASSWORD`, and MongoDB uses `MONGO_INITDB_ROOT_PASSWORD`. Your connection info appears in a bar at the top: host, port, user, database, and password (masked by default, with a toggle to reveal). No more digging through Docker Compose files or `docker inspect` output. ### Step 3: Command Generation With the database type identified and credentials extracted, Server Compass generates complete commands organized by category: - **Connect** — Open an interactive shell session - **Tables** — List tables, describe structure, create/drop tables - **Records** — Select, insert, update, delete operations - **Database** — Show databases, size info, version - **Backup** — Export data with mysqldump, pg\_dump, mongodump - **Users** — List users, create users, grant permissions - **Config** — View configuration variables ## CLI vs cURL: Both Covered Not all databases work the same way. Some require native CLI tools, others expose HTTP APIs. For databases like MySQL, PostgreSQL, and MongoDB, Server Compass generates CLI commands that require the respective client tool (`mysql`, `psql`, `mongosh`). Each command shows the required tool, and there's an install guide showing how to install it on macOS, Linux, and Windows. For databases with HTTP interfaces like ClickHouse, Elasticsearch, InfluxDB, and CouchDB, Server Compass generates cURL commands instead. These work on any machine with cURL installed—no database-specific client needed. ``` # ClickHouse - cURL command curl "http://your-server:8123/?query=SELECT+name+FROM+system.tables" # MySQL - CLI command mysql -h your-server -P 3306 -u root -p'yourpassword' -e "SHOW TABLES;" mydb ``` ## CRUD Filtering: Find Commands Fast With dozens of commands available, finding the right one could become its own problem. That's why every command is tagged with its CRUD type: - **Create** — Commands that create tables, insert records, add users - **Read** — Commands that query data, describe structures, list items - **Update** — Commands that modify existing data - **Delete** — Commands that remove data (highlighted for caution) - **Admin** — Commands for connection, configuration, and maintenance Click any filter button, and you see matching commands from *all* categories. Need to delete something? Filter by Delete and see every destructive command in one view, regardless of whether it's table-level or record-level. ## Dynamic Placeholders Many commands need a table name, collection name, or key. Instead of generating commands with placeholder text you'd need to manually edit, Server Compass prompts you to enter the value directly. Commands that need input show a "Needs input" badge. When you expand the command, a text field appears. Type your table name, and it's instantly substituted into the command—both in the preview and when you copy or execute it. ## Three Ways to Execute Once you have the right command, you have three options: 1. **Copy** — Copy the complete command to your clipboard 2. **Run Local** — Open the command in your local terminal (Terminal on Mac, Windows Terminal on Windows) 3. **Run on Server** — Execute directly on the remote server via Server Compass's [SSH terminal](/features/ssh-terminal) The "Run on Server" option is particularly powerful for commands that need to run inside the Docker network. Instead of exposing your database port publicly, you can execute commands through Server Compass's secure SSH connection. ## Security by Default Passwords are masked in the command preview by default. You see `***` instead of your actual password, preventing accidental exposure during screen shares or over-the-shoulder moments. Click the eye icon to toggle visibility when you need it. When you copy a command, it includes the real password—the masking is purely visual. The command you paste or execute always works correctly. ## What Can You Do? Here's a sampling of operations available out of the box: ### MySQL / MariaDB - Connect to database shell - List/describe/create/drop tables - Select, insert, update, delete records - Show processlist, kill queries - Full and partial mysqldump backups - Create users and grant privileges ### PostgreSQL - Connect with psql - List tables, describe schema - Query and modify data - pg\_dump full and schema-only exports - Role and permission management - View and modify configuration ### MongoDB - Connect with mongosh - List collections, show indexes - Find, insert, update, delete documents - Aggregation pipeline templates - mongodump and mongorestore - User and role management ### Redis - Connect with redis-cli - Get, set, delete keys - Scan keys by pattern - Check memory usage - BGSAVE and backup - Server info and stats ### ClickHouse - Query via cURL HTTP API - List databases and tables - Insert and select data - System tables and metrics - Kill running queries ## Why This Matters Every minute spent searching for command syntax is a minute not spent solving actual problems. Database Commands removes that friction entirely. Deploy a [MySQL database](/templates/mysql), click the container, and you have every command you need—with your credentials already filled in. No documentation lookup, no copy-paste errors, no "was it `-p` or `-P`?" moments. This is especially valuable when you're managing multiple databases across multiple servers. Each deployment has different credentials, different ports, different database names. Server Compass keeps track of all of it and generates the right commands for each context. ## Get Started The Database Commands feature is available in Server Compass. Deploy any supported database using the [template gallery](/features/template-deployment), click on the container, and start generating commands instantly. Check out our database deployment tutorials to see it in action: - [Install MySQL on VPS](/tutorials/install-mysql-vps) - [Deploy PostgreSQL on VPS](/tutorials/deploy-postgresql-vps) - [Deploy and Manage MongoDB](/tutorials/deploy-manage-mongodb-vps) - [Self-Host ClickHouse](/tutorials/install-clickhouse-vps) Ready to stop googling database commands? [Download Server Compass](/) and reclaim your productivity. --- **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. --- ## Server Snapshots: One-File Disaster Recovery for Your Entire VPS Setup Source: https://servercompass.app/blog/server-snapshots-disaster-recovery Published: 2026-03-11 Tags: backups, disaster-recovery, migration, server-management, self-hosted Export your entire server configuration — Docker stacks, databases, domains, cron jobs — to a single encrypted .scz file. Restore to the same server or migrate to a new one. Your VPS has 12 apps running with custom Docker Compose configs, 8 domains with SSL certificates, 5 cron jobs, a dozen alert rules, and environment variables scattered across everything. If you needed to rebuild this setup on a new server tomorrow, how long would it take? Hours? Days? Server Compass v1.17.0 introduces Server Snapshots—export your entire server configuration to a single encrypted `.scz` file and restore it anywhere. ## What Gets Captured A server snapshot captures everything Server Compass manages: - Docker stacks and Compose configurations - Docker volumes and persistent data - Database configurations and data - Domain mappings and SSL settings - Cron job schedules and scripts - Alert rules and notification settings - Environment variables and secrets ## Save Locally or Upload to S3 Save snapshots to your local machine for manual backup, or upload directly to your S3-compatible cloud storage. Either way, the file is encrypted so your credentials and secrets are protected at rest. ## Three Restore Scenarios ### Disaster Recovery Your server went down. Spin up a new VPS, connect it to Server Compass, and restore the snapshot. All your apps, domains, databases, and cron jobs are back. ### Server Migration Moving from DigitalOcean to Hetzner? Snapshot your existing server, restore to the new one. Domain handling options let you keep original domains, strip all domains (for a clean start), or remap to new domains. ### Server Cloning Need an identical staging server? Snapshot production, restore to a fresh VPS, remap domains to staging subdomains. Exact replica in minutes. ## SQL Server (MSSQL) Support in DbAdmin Also in this release: the [database admin panel](/features/database-admin) now supports SQL Server (MSSQL). Browse tables, view data, run SQL queries, and import/export databases—the same workflow you know from PostgreSQL and MySQL. ## Protect Your Setup A snapshot takes seconds to create and can save days of manual reconfiguration. [Try Server Compass](https://servercompass.app) and create your first server snapshot today. --- **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'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. --- ## How to Create a robots.txt File for the AI Era (2026 Guide) Source: https://servercompass.app/blog/how-to-create-robots-txt-ai-era Published: 2026-03-11 Tags: seo, ai, tools, security, best-practices Learn how to generate robots.txt files that control both search engine crawlers and AI bots like GPTBot, ClaudeBot, and Perplexity. Complete guide with examples, directives, and a free robots.txt generator tool. The humble `robots.txt` file has been around since 1994, but in 2026 it's more important than ever. With AI companies crawling the web to train their models, you now need to decide not just which search engines can index your content, but which AI systems can learn from it. This guide covers everything you need to know to **create a robots.txt** file that works for both traditional search crawlers and the new wave of AI bots. Plus, we've built a [free robots.txt generator](/tools/robots-txt-generator) to make the process even easier. ![robots.txt file structure showing how to block AI bots and allow search engines](/blogs/robotstxt.jpg) ## What Is robots.txt and Why Does It Matter? A `robots.txt` file is a plain text file placed at the root of your website (e.g., `https://example.com/robots.txt`) that tells web crawlers which pages or sections of your site they can or cannot access. **Important:** robots.txt is a *directive*, not a security measure. Well-behaved bots follow it, but malicious scrapers ignore it. Think of it as a "please do not disturb" sign rather than a lock. ### Why It Matters More in 2026 Three major shifts have made robots.txt crucial: 1. **AI training data** — Companies like OpenAI, Anthropic, Google, and others crawl websites to train large language models. Your content could be used without compensation. 2. **Server resources** — Aggressive AI crawlers can hammer your server with requests, costing you bandwidth and degrading performance. 3. **Content licensing** — Publishers now need granular control over who can use their content and how. ## Basic robots.txt Syntax Before you **generate robots.txt** files, you need to understand the basic directives: ### User-agent Specifies which crawler the rules apply to. Use `*` for all bots: `User-agent: * Disallow: /private/ User-agent: Googlebot Allow: /` ### Disallow and Allow `Disallow` blocks access to a path. `Allow` permits access (useful for exceptions): `User-agent: * Disallow: /admin/ Disallow: /api/ Allow: /api/public/` ### Sitemap Points crawlers to your XML sitemap for better indexing: `Sitemap: https://example.com/sitemap.xml` ### Crawl-delay Requests a delay between requests (in seconds). Not all bots respect this: `User-agent: * Crawl-delay: 10` ## AI Bots You Should Know About To **create robots.txt** rules for AI crawlers, you first need to know their user-agent strings. Here are the major ones: Bot Name User-agent Company Purpose GPTBot `GPTBot` OpenAI Training data for GPT models ChatGPT-User `ChatGPT-User` OpenAI Real-time browsing in ChatGPT ClaudeBot `ClaudeBot` Anthropic Training data for Claude Claude-Web `Claude-Web` Anthropic Real-time web access in Claude Google-Extended `Google-Extended` Google Gemini/Bard training (separate from search) Bytespider `Bytespider` ByteDance Training data for TikTok AI PerplexityBot `PerplexityBot` Perplexity AI AI search engine Amazonbot `Amazonbot` Amazon Alexa answers and AI training FacebookBot `FacebookBot` Meta AI training for Meta products cohere-ai `cohere-ai` Cohere Training enterprise AI models Applebot-Extended `Applebot-Extended` Apple Apple Intelligence training ## Should You Let AI Bots Crawl Your Site in 2026? This is the million-dollar question every website owner faces. There's no universal answer — it depends on your content, business model, and values. Let's break down both sides. ### Reasons to Block AI Crawlers **1\. Your content is your product.** If you're a publisher, journalist, or content creator, AI companies are essentially taking your work to build products that compete with you. They profit from your content without compensation. The New York Times, Reddit, and many publishers have blocked AI crawlers for this reason. **2\. No licensing agreements.** Unlike search engines that drive traffic back to your site, AI training bots take your content and use it to generate answers that may never link back. You get nothing in return. **3\. Server resources.** AI crawlers can be aggressive. GPTBot and others may send thousands of requests, consuming bandwidth and server resources you're paying for. **4\. Data privacy concerns.** If your site contains user-generated content, forum discussions, or personal information, allowing AI training raises privacy and ethical questions. **5\. Future-proofing.** Once your content is in a training dataset, you can't remove it. Blocking now prevents future regret. ### Reasons to Allow AI Crawlers **1\. AI-powered search visibility.** Perplexity, ChatGPT with browsing, and Google's AI Overviews are becoming how people find information. If you block these bots, your content won't appear in AI-generated answers, potentially losing significant traffic. **2\. Brand awareness.** When AI assistants cite or recommend your brand, product, or service, it builds awareness. Some businesses see this as free marketing. **3\. The ship has sailed.** If your site has been public for years, your content is likely already in training datasets. Blocking now only prevents future updates from being included. **4\. Licensing deals are emerging.** Companies like OpenAI, Google, and Apple are signing content licensing agreements with publishers. Allowing crawling today might position you for paid partnerships tomorrow. **5\. Open web philosophy.** Some believe in keeping the web open and accessible. If you benefited from others' open content, paying it forward feels right. ### The Middle Ground: Selective Access You don't have to choose all-or-nothing. Many site owners take a nuanced approach: - **Allow real-time browsing bots** (ChatGPT-User, Claude-Web) that cite sources and drive traffic, while blocking training bots (GPTBot, ClaudeBot). - **Protect premium content** behind paywalls or member areas while allowing AI access to free content. - **Allow specific companies** you trust or have relationships with while blocking others. - **Monitor and adjust** — start permissive, track the impact on traffic and server load, then tighten as needed. ### Our Recommendation for 2026 For most websites, we recommend a **selective blocking approach**: 1. **Block aggressive training bots** like GPTBot, ClaudeBot, and Bytespider unless you have a licensing deal. 2. **Allow AI search bots** like PerplexityBot and Google-Extended if visibility in AI answers matters to your business. 3. **Always allow traditional search engines** — blocking Googlebot hurts you more than anyone. 4. **Protect sensitive directories** regardless of bot type. Use our [robots.txt generator](/tools/robots-txt-generator) to implement this exact strategy with a few clicks. ## robots.txt Examples for Common Scenarios ### Block All AI Bots (Keep Search Engines) If you want search engines to index your site but block AI training crawlers: `# Allow search engines User-agent: Googlebot Allow: / User-agent: Bingbot Allow: / # Block AI training bots User-agent: GPTBot Disallow: / User-agent: ChatGPT-User Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Claude-Web Disallow: / User-agent: Google-Extended Disallow: / User-agent: PerplexityBot Disallow: / User-agent: Bytespider Disallow: / User-agent: Amazonbot Disallow: / User-agent: FacebookBot Disallow: / User-agent: cohere-ai Disallow: / User-agent: Applebot-Extended Disallow: / # Default allow for other bots User-agent: * Allow: / Sitemap: https://example.com/sitemap.xml` ### Allow Only Specific AI Bots If you want to allow some AI companies (perhaps those with licensing deals) while blocking others: `# Allow Google AI (you use their services) User-agent: Google-Extended Allow: / # Allow Perplexity (they link back) User-agent: PerplexityBot Allow: / # Block training-focused bots User-agent: GPTBot Disallow: / User-agent: ClaudeBot Disallow: / User-agent: Bytespider Disallow: / User-agent: * Allow: / Sitemap: https://example.com/sitemap.xml` ### Protect Specific Content Allow AI bots on most pages but protect premium or sensitive content: `User-agent: GPTBot Disallow: /premium/ Disallow: /members/ Disallow: /api/ Allow: / User-agent: ClaudeBot Disallow: /premium/ Disallow: /members/ Disallow: /api/ Allow: / User-agent: * Disallow: /admin/ Disallow: /api/internal/ Allow: / Sitemap: https://example.com/sitemap.xml` ### Aggressive Blocking (Maximum Privacy) Block everything except essential search engines: `# Only allow major search engines User-agent: Googlebot Allow: / User-agent: Bingbot Allow: / User-agent: DuckDuckBot Allow: / User-agent: Yandex Allow: / # Block everything else User-agent: * Disallow: / Sitemap: https://example.com/sitemap.xml` ## Use Our Free robots.txt Generator Manually writing robots.txt rules can be tedious and error-prone. That's why we built a **robots.txt generator** that makes it easy to: - Select which search engines to allow - Choose which AI bots to block or allow - Add custom disallow paths - Include your sitemap URL - Copy or download the generated file [Try the free robots.txt generator tool](/tools/robots-txt-generator) — no signup required. ## Where to Place Your robots.txt File After you **create robots.txt**, place it at the root of your domain: `https://example.com/robots.txt ✓ Correct https://example.com/files/robots.txt ✗ Wrong https://www.example.com/robots.txt ✓ Correct (but separate from non-www)` **Note:** Subdomains need their own robots.txt files. `blog.example.com` and `example.com` are treated as separate sites. ### Framework-Specific Placement Framework Location Next.js (App Router) `app/robots.txt` or `public/robots.txt` Next.js (Pages Router) `public/robots.txt` React (CRA/Vite) `public/robots.txt` Vue/Nuxt `public/robots.txt` or `static/robots.txt` WordPress Root of WordPress installation (or use Yoast SEO) Laravel `public/robots.txt` Django `static/robots.txt` or serve via URL route ## Testing Your robots.txt After you generate and deploy your robots.txt, verify it works: ### Google Search Console Use the [robots.txt Tester](https://search.google.com/search-console/robots-testing-tool) in Google Search Console to check for syntax errors and test specific URLs. ### Manual Testing Simply visit your robots.txt URL directly: `curl https://yourdomain.com/robots.txt` ## Common robots.txt Mistakes to Avoid ### 1\. Blocking CSS and JavaScript Blocking `/css/` or `/js/` directories prevents search engines from rendering your pages properly, hurting SEO: `# Don't do this User-agent: * Disallow: /css/ Disallow: /js/` ### 2\. Forgetting Trailing Slashes `Disallow: /admin` blocks `/admin`, `/admin/`, and `/administrator`. Be specific with `Disallow: /admin/` if you only want to block the directory. ### 3\. Case Sensitivity Paths in robots.txt are case-sensitive. `/Admin/` and `/admin/` are different. ### 4\. Using robots.txt for Security Never rely on robots.txt to protect sensitive data. It's publicly readable and malicious bots ignore it. Use authentication and access controls instead. ## Beyond robots.txt: Additional Controls robots.txt is just one layer. Consider these additional methods: ### Meta Robots Tag Page-level control in your HTML: ` ` ### X-Robots-Tag Header Server-level control for non-HTML files (PDFs, images): `X-Robots-Tag: noindex, nofollow` ### Rate Limiting If AI bots are hammering your server despite robots.txt rules, implement rate limiting at the server or CDN level. Cloudflare, Nginx, and most reverse proxies support this. ## Conclusion Creating a robots.txt file in 2026 requires thinking beyond just search engines. With AI crawlers actively scraping the web for training data, you need a strategy that balances discoverability with content protection. Key takeaways: - **Know the bots** — GPTBot, ClaudeBot, Google-Extended, and others have distinct user-agents you can target. - **Be explicit** — List each AI bot you want to block rather than relying on catch-all rules. - **Test thoroughly** — Use Google Search Console and manual checks to verify your rules. - **Layer your defenses** — Combine robots.txt with meta tags, headers, and rate limiting. Ready to create your own? Use our [free robots.txt generator](/tools/robots-txt-generator) to build a customized file in seconds. --- **Related in the StoicSoft network** If you work in AI-assisted coding, shared terminal sessions, or agent-driven shell workflows like the ones above, [1devtool](https://1devtool.com) is the StoicSoft network's tool for safer AI-assisted terminal work — shared sessions with auditing, preflight policy, and tiered model routing built in. --- ## Sync Your Server Compass Data Across Devices with End-to-End Encryption Source: https://servercompass.app/blog/cross-device-sync-encrypted Published: 2026-03-10 Tags: sync, encryption, backups, server-management Push and pull your Server Compass configuration across Mac, Windows, and Linux using your own S3-compatible storage with end-to-end encryption and conflict detection. You manage servers from your desktop at the office and your laptop at home. But Server Compass stores its configuration locally, so your laptop doesn't know about the servers you added on your desktop. You end up re-adding connections, re-entering credentials, and duplicating work across devices. Server Compass v1.16.3 solves this with cross-device sync. Push your data from one device, pull it on another—encrypted end-to-end through your own S3-compatible storage. ## How Cross-Device Sync Works Connect any S3-compatible storage provider (the same ones you use for [cloud backups](/blog/cloud-backup-s3-encrypted)). Then: - **Push** — uploads your current Server Compass data to cloud storage, encrypted with your passphrase - **Pull** — downloads the latest data from cloud storage to your current device Your data is encrypted with your backup passphrase before it leaves your device. The cloud provider stores only encrypted blobs—they can't read your server credentials, API keys, or any configuration data. ## Device Tracking See which devices have synced and when they last pushed or pulled. This gives you confidence that all your machines are up to date, and helps you identify which device has the latest changes. ## Conflict Detection When both your local data and the remote data have been modified since the last sync, Server Compass detects the conflict and asks which version to keep. No silent overwrites—you always choose. ## Works Across Mac, Windows, and Linux Sync works across all platforms Server Compass supports. Manage your servers from a Mac at the office, a Windows desktop at home, and a Linux laptop on the road—all with the same configuration. ## Sync Your Setup If you already have cloud backups configured, cross-device sync uses the same S3 connection. Enable it in Settings and your data follows you everywhere. [Download Server Compass](https://servercompass.app) on all your devices. --- ## 7 Self-Hosted Alternatives to Vercel, Railway & Render (2026) Source: https://servercompass.app/blog/best-self-hosted-deployment-platforms-2026 Published: 2026-03-06 Tags: self-hosted, deployment, docker, vps-deploy, comparisons Tired of PaaS bills? Compare 7 self-hosted deployment platforms — Server Compass, Coolify, CapRover, Dokploy, Kamal, and more. Deploy to your own VPS for $5/mo instead of $50+/mo. The landscape of self-hosted deployment platforms has evolved dramatically. In 2026, developers have more choices than ever for deploying applications to their own servers — without relying on expensive PaaS providers like Vercel, Railway, or Render. Whether you're an indie developer looking to cut costs, an agency managing multiple client projects, or a team that needs full control over your infrastructure, there's a self-hosted deployment platform that fits your needs. This comprehensive guide compares the best options available today. ## Why Self-Host Your Deployments in 2026? Before diving into specific platforms, let's address why self-hosted deployment platforms have become so popular: ### Dramatic Cost Savings PaaS pricing has become increasingly aggressive. Vercel Pro costs $20/seat/month plus bandwidth overages. Railway charges per resource-second. A single production app with a database can easily cost $50-100/month on these platforms. Meanwhile, a $6/month VPS from Hetzner or DigitalOcean can run 5-10 applications simultaneously. Self-hosting cuts your infrastructure costs by 70-90% in most scenarios. ### Data Sovereignty and Privacy With increasing privacy regulations (GDPR, CCPA, and newer 2026 mandates), knowing exactly where your data lives matters. Self-hosting means your customer data never touches third-party infrastructure you don't control. ### No Vendor Lock-In PaaS platforms love proprietary features. Vercel's Edge Functions, Railway's networking, Render's managed databases — they all work slightly differently from standard tooling. Self-hosted platforms use standard Docker containers that run anywhere. ### Full Control Over Your Stack Need a specific version of Node.js? Custom nginx configuration? Persistent file storage? Long-running background processes? Self-hosting gives you complete control over every aspect of your deployment environment. ## What Makes a Good Self-Hosted Deployment Platform? When evaluating self-hosted deployment platforms, consider these key criteria: - **Ease of Setup** — How quickly can you go from a fresh VPS to a deployed application? - **Git Integration** — Does it support automatic deployments from GitHub, GitLab, or Bitbucket? - **SSL/HTTPS** — Automatic certificate provisioning with Let's Encrypt is essential. - **Database Support** — Can you easily deploy and manage PostgreSQL, MySQL, MongoDB, and Redis? - **Zero-Downtime Deployments** — Blue-green or rolling deployments prevent outages during updates. - **Resource Monitoring** — CPU, memory, and disk usage visibility is crucial for production apps. - **Multi-Server Support** — Can you manage multiple VPS instances from one interface? - **Pricing Model** — One-time vs subscription, open source vs commercial. - **Community and Support** — Active development, documentation quality, community resources. ## Top Self-Hosted Deployment Platforms in 2026 ### 1\. Server Compass — Best Desktop App for VPS Deployment **Type:** Desktop application (Mac, Windows, Linux) **Best For:** Developers who want Vercel-like UX on their own VPS **Pricing:** $29 one-time purchase Server Compass takes a fundamentally different approach from other platforms on this list. Instead of installing software on your server, it's a desktop application that connects to your VPS via SSH. This means zero server-side overhead — no agents, no dashboards consuming your server resources. ![Server Compass dashboard showing running containers with real-time monitoring](/app-screenshots/feature-container-status.jpg) #### Key Features - **Framework Auto-Detection** — [Automatically detects 16+ frameworks](/features/framework-detection) (Next.js, Django, Laravel, Go, Rust, etc.) and generates optimized Dockerfiles - **Three Build Options** — Build on VPS, build locally on your machine, or via [GitHub Actions CI/CD](/features/github-actions) - **166+ One-Click Templates** — [Deploy WordPress, PostgreSQL, Redis, Supabase](/templates), and more instantly - **Zero-Downtime Deployments** — [Blue-green deployment](/features/zero-downtime) prevents any downtime during updates - **Visual Database Management** — [Built-in SQL editor, table browser, and backup tools](/features/db-admin) - **Encrypted Environment Variables** — [AES-256-GCM encrypted .env vault](/features/env-vault) that never leaves your machine - **Security Tools** — [Security audit](/features/security-audit), [UFW firewall management](/features/ufw-firewall), [Fail2ban configuration](/features/fail2ban) - **Real-Time Monitoring** — CPU, memory, disk, and network usage with container-level metrics #### Why Server Compass Stands Out Unlike web-based platforms that run on your server, Server Compass connects only when needed. Your server resources go entirely to your applications, not to running a deployment dashboard. This is particularly important on smaller VPS instances where every MB of RAM counts. The one-time $29 pricing is also compelling. Compare that to Coolify Cloud ($9/month) or commercial tools like Ploi ($8/month) — Server Compass pays for itself in 3-4 months. #### Potential Drawbacks - Desktop-only (no web dashboard to access from anywhere) - Not open source - Requires SSH access to your server [Learn more about Server Compass](/) | [Compare to Coolify](/compare/coolify) | [Compare to CapRover](/compare/caprover) ### 2\. Coolify — Best Open-Source Self-Hosted PaaS **Type:** Self-hosted web application **Best For:** Teams wanting an open-source Heroku/Vercel alternative **Pricing:** Free (self-hosted) or $9/month (managed cloud) Coolify is the most popular open-source self-hosted deployment platform. It installs on your server and provides a web-based dashboard for managing applications, databases, and services. Think of it as a self-hosted Heroku. #### Key Features - **Git-Based Deployments** — Connect GitHub, GitLab, or Bitbucket for automatic deployments - **One-Click Services** — Deploy PostgreSQL, MySQL, MongoDB, Redis, and many other services - **Automatic SSL** — Let's Encrypt certificates with automatic renewal - **Docker Compose Support** — Deploy complex multi-container applications - **Server Management** — Manage multiple servers from one dashboard - **Team Features** — Multiple users with role-based access control #### Potential Drawbacks - **Server Resource Usage** — The dashboard runs on your server, consuming RAM and CPU - **Complexity** — More moving parts means more potential failure points - **Learning Curve** — The interface can be overwhelming for beginners - **Single Point of Failure** — If the Coolify instance goes down, you lose deployment capabilities [Server Compass vs Coolify comparison](/compare/coolify) ### 3\. CapRover — Best for Simple Docker Deployments **Type:** Self-hosted PaaS **Best For:** Developers familiar with Docker who want quick deployments **Pricing:** Free (open source) CapRover has been around since 2017 and remains a solid choice for developers who want a straightforward way to deploy Docker containers. It uses nginx as a reverse proxy and includes built-in Let's Encrypt support. #### Key Features - **One-Click Apps** — App store with 100+ pre-built applications - **CLI Deployment** — Deploy from command line with \`caprover deploy\` - **Cluster Mode** — Scale across multiple servers with Docker Swarm - **Persistent Volumes** — Easy persistent storage management - **Web Terminal** — SSH into containers from the browser #### Potential Drawbacks - **Dated UI** — The interface feels less modern than newer alternatives - **Limited Git Integration** — GitHub integration is basic compared to Coolify - **Docker Swarm** — Uses Docker Swarm instead of Kubernetes (less popular in 2026) - **Single-Node Focus** — While cluster mode exists, it's primarily designed for single-server use [Server Compass vs CapRover comparison](/compare/caprover) ### 4\. Dokploy — Best Vercel-Style Open Source Alternative **Type:** Self-hosted web application **Best For:** Developers who love Vercel's UI but want self-hosting **Pricing:** Free (open source) Dokploy is a newer entrant that has gained significant traction in 2025-2026. It aims to replicate the Vercel experience with a clean, modern UI while being completely self-hosted. #### Key Features - **Modern UI** — Beautiful, Vercel-inspired interface - **Preview Deployments** — Automatic preview URLs for pull requests - **Traefik Integration** — Uses Traefik for routing and SSL - **Docker Compose** — Native support for docker-compose.yml files - **Real-Time Logs** — Stream application logs in the browser - **Multi-Project Support** — Organize apps into projects #### Potential Drawbacks - **Newer Project** — Less battle-tested than Coolify or CapRover - **Smaller Community** — Fewer community resources and templates - **Limited Database Tools** — No built-in database management UI - **Server Resource Usage** — Like Coolify, runs on your server [Server Compass vs Dokploy comparison](/compare/dokploy) ### 5\. Kamal — Best for Ruby/Rails Developers **Type:** CLI deployment tool **Best For:** Rails developers and 37signals-style deployment **Pricing:** Free (open source, from 37signals) Kamal (formerly MRSK) is 37signals' answer to deployment. It's the tool they use to deploy Basecamp, HEY, and their other products. Unlike other platforms on this list, Kamal is a CLI tool rather than a web dashboard. #### Key Features - **Zero-Downtime Deploys** — Rolling deployments with health checks - **Multi-Server** — Deploy to multiple servers simultaneously - **Traefik Router** — Automatic SSL and load balancing - **Accessory Services** — Deploy databases and other services alongside your app - **Configuration as Code** — Everything defined in deploy.yml - **Production-Tested** — Powers major production apps #### Potential Drawbacks - **CLI Only** — No web interface; everything is done via terminal - **Ruby-Centric** — While it works with any Docker app, the ecosystem is Ruby-focused - **Learning Curve** — Requires understanding of Docker and YAML configuration - **No GUI Monitoring** — You need separate tools for server monitoring [Server Compass vs Kamal comparison](/compare/kamal) ### 6\. Portainer — Best Docker Management UI **Type:** Docker management platform **Best For:** Teams who want visual Docker/Kubernetes management **Pricing:** Free Community Edition, $15/node/month Business Portainer isn't strictly a deployment platform — it's a Docker and Kubernetes management UI. However, many developers use it to manage their self-hosted applications, making it worth including here. #### Key Features - **Visual [Container Management](https://1devtool.com/features/docker-containers)** — Start, stop, restart, and inspect containers - **Stack Deployments** — Deploy docker-compose stacks visually - **Kubernetes Support** — Manage K8s clusters alongside Docker - **Volume Management** — Visual interface for Docker volumes - **Network Management** — Configure Docker networks visually - **Multi-Environment** — Manage multiple Docker/Kubernetes environments #### Potential Drawbacks - **Not a Deployment Platform** — No Git integration or CI/CD features - **No Automatic SSL** — You need to configure SSL manually or with Traefik - **No Build System** — You must build images yourself or use another tool - **Business Features Locked** — RBAC and some features require paid plan ## Feature Comparison Table Feature Server Compass Coolify CapRover Dokploy Kamal Portainer **Type** Desktop App Web Dashboard Web Dashboard Web Dashboard CLI Tool Web Dashboard **Pricing** $29 one-time Free / $9/mo Free Free Free Free / $15/node **Git Integration** GitHub GitHub, GitLab Basic GitHub, GitLab None None **Framework Detection** 16+ frameworks Nixpacks Buildpacks Nixpacks None None **Zero-Downtime Deploy** Yes Yes Limited Yes Yes Manual **Database Management** Visual Editor Basic None None None None **Templates** 166+ 100+ 100+ 50+ None None **Server Resources** None (desktop) ~500MB RAM ~300MB RAM ~400MB RAM None (CLI) ~200MB RAM **Multi-Server** Unlimited Unlimited Cluster Mode Yes Yes Yes **Open Source** No Yes Yes Yes Yes Partial ## Pricing Comparison: What You'll Actually Pay Let's calculate real-world costs for a typical setup: 3 applications, 2 databases, running on a single VPS. Platform Platform Cost VPS Cost Year 1 Total Year 2+ Annual **Server Compass** $29 one-time $6/month $101 $72 **Coolify (self-hosted)** Free $10/month\* $120 $120 **Coolify Cloud** $9/month $6/month $180 $180 **CapRover** Free $10/month\* $120 $120 **Dokploy** Free $10/month\* $120 $120 **Kamal** Free $6/month $72 $72 **Portainer CE** Free $6/month $72 $72 *\* Web-based platforms consume server resources, so you typically need a larger VPS (4GB RAM vs 2GB).* For comparison, running the same setup on PaaS platforms: - **Vercel + Railway**: $20/seat + ~$25/month for databases = $540/year minimum - **Render**: 3 apps ($7 each) + 2 databases ($7 each) = $420/year - **Railway**: Usage-based, typically $30-60/month = $360-720/year ## Why Server Compass Is the Best Choice for Most Developers After evaluating all options, Server Compass emerges as the top recommendation for most developers. Here's why: ### Zero Server Overhead Unlike Coolify, CapRover, and Dokploy — which run on your server and consume resources — Server Compass is a desktop application. It connects via SSH only when you're actively managing your server. On a 2GB RAM VPS, this difference is significant. Web-based platforms might consume 300-500MB just for the dashboard, leaving less for your actual applications. ![Server Compass server overview showing system resources and running applications](/app-screenshots/feature-server-overview.jpg) ### Best-in-Class Developer Experience Server Compass provides a Vercel-like experience for VPS deployments: - Connect your GitHub repo, select a branch, click deploy - [Auto-detection of 16+ frameworks](/features/framework-detection) generates optimized Dockerfiles - [GitHub Actions CI/CD](/features/github-actions) automatically generated for continuous deployment - [Zero-downtime blue-green deployments](/features/zero-downtime) by default - Real-time logs, container metrics, and deployment history ### 166+ One-Click Templates Need to deploy WordPress, Ghost, Supabase, Strapi, PostgreSQL, MongoDB, or Redis? Server Compass includes [166+ ready-to-deploy templates](/templates) — more than any other platform on this list. ### Built-In Database Management Most self-hosted deployment platforms stop at "here's your database container." Server Compass includes a [full visual database manager](/features/db-admin) : - SQL editor with syntax highlighting - Table browser and data viewer - One-click backups to S3-compatible storage - Support for PostgreSQL, MySQL, MongoDB, and Redis ![Server Compass database management interface with SQL editor](/app-screenshots/feature-db-admin.jpg) ### Security-First Approach Server Compass includes security tools that others lack: - [Security audit](/features/security-audit) to scan for vulnerabilities - [Visual UFW firewall management](/features/ufw-firewall) - [Fail2ban configuration](/features/fail2ban) to block malicious IPs - [SSH hardening](/features/ssh-hardening) with one click - [AES-256-GCM encrypted .env vault](/features/env-vault) stored locally ### One-Time Pricing At $29 for a lifetime license, Server Compass pays for itself quickly. Deploy to unlimited servers with no monthly fees, no per-seat charges, and no usage limits. ## How to Choose the Right Platform Here's a decision framework based on your specific needs: ### Choose Server Compass if: - You want the easiest path from code to deployed app - You prefer a desktop app over a web dashboard - You want zero server-side overhead - You need visual database management - You want one-time pricing (no subscriptions) - You value built-in security tools - You deploy JavaScript/Python/Go/Rust applications ### Choose Coolify if: - You need a web-accessible dashboard - You want to self-host everything (even the deployment tool) - You need team features with multiple users - Open source is a requirement - You have a larger VPS (4GB+ RAM) with resources to spare ### Choose CapRover if: - You're already familiar with Docker Swarm - You want a battle-tested, stable platform - You need cluster mode for multi-server deployments - You prefer CLI-based deployment workflow ### Choose Dokploy if: - You love Vercel's UI and want something similar - You need preview deployments for pull requests - You want a modern, actively developed platform - You're comfortable with a newer, less mature tool ### Choose Kamal if: - You're a Ruby/Rails developer - You prefer configuration-as-code (YAML) - You want CLI-only workflow (no GUI) - You need multi-server deployment with rolling updates ### Choose Portainer if: - You already have Docker containers and just need to manage them - You need Kubernetes support alongside Docker - You're not looking for a full deployment solution - You want the most lightweight dashboard option ## Self-Hosting vs PaaS: The Real Cost Difference Let's run the numbers on a real-world scenario: a SaaS startup with a Next.js frontend, Node.js API, PostgreSQL database, and Redis cache. ### Scenario A: Using Vercel + Railway - Vercel Pro: $20/month per seat (3 developers = $60/month) - Railway: Node.js API (~$10/month) + PostgreSQL (~$10/month) + Redis (~$5/month) - Bandwidth overages: ~$20/month at moderate traffic - **Monthly total: $105/month = $1,260/year** ### Scenario B: Self-Hosted with Server Compass - Server Compass: $29 one-time - Hetzner VPS (4GB RAM, 2 vCPU): $6/month - Backblaze B2 backups: ~$1/month - **Year 1 total: $113** - **Year 2+ total: $84/year** ### The Savings - Year 1: Save $1,147 (91% reduction) - Year 2: Save $1,176 (93% reduction) - 5-year savings: $5,838 For a bootstrapped startup, that $5,838 could fund 6 months of runway, marketing budget, or additional development resources. ## Getting Started with Self-Hosted Deployment Ready to make the switch? Here's how to get started with Server Compass: ### Step 1: Get a VPS Sign up with any VPS provider. Popular options include: - **Hetzner** — Best value ($4-6/month for 2-4GB RAM) - **DigitalOcean** — Great UX and documentation - **Vultr** — Good global coverage - **Linode** — Reliable with good support For most projects, a $6-10/month VPS with 2-4GB RAM is sufficient. Choose Ubuntu 22.04 or 24.04 LTS as your operating system. ### Step 2: Download Server Compass [Download Server Compass](/) for Mac, Windows, or Linux. The app is a one-time $29 purchase with lifetime updates. ### Step 3: Connect Your Server Open Server Compass, enter your VPS IP address and SSH credentials. The app will automatically configure Docker, set up the firewall, and prepare your server for deployments. ### Step 4: Deploy Your First App You have three options: 1. **Connect GitHub** — Select a repository and branch, Server Compass auto-detects your framework and deploys 2. **Use a Template** — Choose from [166+ one-click templates](/templates) for WordPress, databases, and more 3. **Upload ZIP** — Deploy any application by uploading a ZIP file ![Server Compass framework detection automatically generating Dockerfile](/app-screenshots/feature-framework-detect.jpg) ### Step 5: Configure Your Domain Point your domain's A record to your VPS IP address. In Server Compass, add the domain to your application. SSL certificates are provisioned automatically via Let's Encrypt. ## Frequently Asked Questions ### Do I need DevOps experience to use these platforms? It depends on the platform. **Server Compass** and **Dokploy** are designed to be beginner-friendly — you can deploy without ever touching the terminal. **Coolify** and **CapRover** require some Docker familiarity. **Kamal** assumes command-line proficiency and Docker knowledge. ### Is self-hosting as reliable as Vercel or Railway? With proper setup, yes. Self-hosted platforms support zero-downtime deployments, automatic SSL renewal, and health checks. The main difference is that *you're* responsible for keeping the server updated. Tools like Server Compass include [security audits](/features/security-audit) to help with this. ### What about scaling? Self-hosted platforms support horizontal scaling through multiple servers. Server Compass lets you manage unlimited VPS instances, deploying the same app to multiple servers with a load balancer. For most applications under 100K monthly users, a single well-configured VPS handles the load easily. ### Can I run managed databases instead? Absolutely. Many developers combine self-hosted apps with managed databases like Supabase, PlanetScale, or Neon for the best of both worlds. Server Compass supports any database configuration — self-hosted or external. ### What about Kubernetes? For most applications, Kubernetes is overkill. Docker with proper orchestration (which these platforms provide) handles 95% of use cases. Kubernetes adds significant complexity and resource overhead. If you truly need Kubernetes, consider **Portainer** for management or a managed service like GKE or EKS. ### How do I handle backups? Server Compass includes [one-click database backups](/features/db-admin) to S3-compatible storage (AWS S3, Backblaze B2, DigitalOcean Spaces). For file backups, you can configure automated snapshots through your VPS provider or use tools like restic. ### Do these platforms support automatic SSL? Yes, all platforms listed support automatic SSL via Let's Encrypt. Server Compass, Coolify, CapRover, and Dokploy handle certificate provisioning and renewal automatically. ### What if something breaks? Each platform has different support options: - **Server Compass**: Email support, documentation, community Discord - **Coolify**: Discord community, GitHub issues - **CapRover**: GitHub issues, community forums - **Dokploy**: GitHub issues, Discord - **Kamal**: GitHub issues, Ruby/Rails community ## Conclusion Self-hosted deployment platforms have matured to the point where there's no reason to pay $50-200/month for PaaS services unless you specifically need their unique features. For most developers, **Server Compass** offers the best combination of ease-of-use, features, and value. The desktop app approach means zero server overhead, the 166+ templates cover most deployment needs, and the one-time $29 price means you're not locked into another subscription. If you need a self-hosted web dashboard, **Coolify** is the most feature-complete option, though you'll need a larger VPS to accommodate its resource usage. For CLI enthusiasts working primarily with Ruby/Rails, **Kamal** offers a clean, configuration-as-code approach backed by 37signals' production experience. Ready to take control of your deployments? [Download Server Compass](/) and deploy your first app in under 5 minutes. No terminal required, no monthly fees, just straightforward deployment to your own VPS. --- **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. 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. --- ## Deploy Docker Containers to VPS Without Kubernetes (Simple Guide) Source: https://servercompass.app/blog/deploy-docker-containers-to-vps-without-kubernetes Published: 2026-03-06 Tags: docker, deployment, vps-deploy, tutorials, self-hosted Learn how to deploy Docker containers to your VPS without the complexity of Kubernetes. This comprehensive guide covers Docker installation, Dockerfile creation, Docker Compose, Traefik reverse proxy, and container management for production workloads. Kubernetes is powerful, but for most projects it's overkill. If you're deploying a web app, API, or side project to a VPS, you don't need a container orchestration platform designed for thousands of nodes. You need Docker, Docker Compose, and maybe a reverse proxy. This guide shows you how to deploy Docker containers to your VPS the simple way — no Kubernetes, no complex YAML manifests, no steep learning curve. Just straightforward container deployment that scales from side projects to production workloads. By the end of this guide, you'll know how to install Docker, write Dockerfiles, use Docker Compose for multi-container apps, set up Traefik for automatic SSL, manage persistent data, and keep your containers running reliably. ## Why Docker on VPS Beats Kubernetes for Most Projects Before we dive in, let's address the elephant in the room: when does Kubernetes actually make sense? Kubernetes shines when you need: - Horizontal auto-scaling across multiple nodes - Automated failover between physical machines - Multi-region deployments with complex networking - Teams of 10+ engineers managing hundreds of microservices For everyone else — indie developers, small teams, agencies, and most startups — Docker on a single VPS (or a few VPS instances) is simpler, cheaper, and faster to set up. Here's the reality: a $20/month VPS with 4 CPUs and 8GB RAM can handle more traffic than most applications will ever see. Add Docker Compose for container orchestration and Traefik for SSL termination, and you have a production-ready stack in under an hour. With Kubernetes, you'd spend days learning concepts like Pods, Deployments, Services, Ingress Controllers, ConfigMaps, Secrets, and PersistentVolumeClaims — all before deploying your first container. ## Prerequisites Before you start, make sure you have: - **A VPS with Ubuntu 22.04 or 24.04** — Hetzner, DigitalOcean, Linode, Vultr, or any provider works. Minimum 1GB RAM, 2GB+ recommended. - **SSH access** — You should be able to connect via `ssh root@your-server-ip` or with a sudo-enabled user. - **A domain name (optional but recommended)** — Required for SSL certificates. Point an A record to your VPS IP. - **Basic terminal knowledge** — You should be comfortable running commands and editing files. Don't have a VPS yet? Hetzner offers excellent value at $4-6/month for capable servers. DigitalOcean and Vultr are also solid choices starting at $5-6/month. ## Step 1: Install Docker on Ubuntu VPS First, SSH into your server and update the package list: ``` ssh root@your-server-ip # Update packages apt update && apt upgrade -y ``` The easiest way to install Docker is using the official convenience script: ``` # Install Docker using the official script curl -fsSL https://get.docker.com -o get-docker.sh sh get-docker.sh # Verify installation docker --version # Docker version 26.x.x, build xxxxx # Check Docker is running systemctl status docker ``` If you're using a non-root user, add them to the `docker` group: ``` # Add your user to docker group (replace 'username' with your actual username) usermod -aG docker username # Log out and back in for group changes to take effect exit ssh username@your-server-ip # Verify you can run docker without sudo docker ps ``` Docker Compose comes bundled with modern Docker installations as a plugin. Verify it's available: ``` # Check Docker Compose version docker compose version # Docker Compose version v2.x.x ``` ## Step 2: Basic Docker Commands Before deploying your app, let's cover the essential Docker commands you'll use daily: ``` # Pull an image from Docker Hub docker pull nginx:alpine # Run a container docker run -d --name my-nginx -p 80:80 nginx:alpine # List running containers docker ps # List all containers (including stopped) docker ps -a # View container logs docker logs my-nginx docker logs -f my-nginx # Follow logs in real-time # Stop a container docker stop my-nginx # Start a stopped container docker start my-nginx # Remove a container docker rm my-nginx # Remove a container forcefully (even if running) docker rm -f my-nginx # List images docker images # Remove an image docker rmi nginx:alpine # Execute a command inside a running container docker exec -it my-nginx /bin/sh # View container resource usage docker stats ``` These commands form the foundation of Docker operations. You'll use them constantly for debugging, monitoring, and managing containers. ## Step 3: Create a Dockerfile for Your App A Dockerfile tells Docker how to build your application into a container image. Here are optimized Dockerfiles for common frameworks: ### Node.js / Express Dockerfile ``` # Use official Node.js LTS image FROM node:20-alpine AS builder WORKDIR /app # Copy package files first (better layer caching) COPY package*.json ./ # Install dependencies RUN npm ci --only=production # Copy application code COPY . . # Production stage FROM node:20-alpine AS runner WORKDIR /app # Create non-root user for security RUN addgroup -g 1001 -S nodejs && adduser -S nodejs -u 1001 # Copy from builder COPY --from=builder --chown=nodejs:nodejs /app ./ USER nodejs EXPOSE 3000 CMD ["node", "server.js"] ``` ### Next.js Dockerfile ``` FROM node:20-alpine AS deps WORKDIR /app COPY package.json pnpm-lock.yaml* ./ RUN corepack enable && pnpm install --frozen-lockfile FROM node:20-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN corepack enable && pnpm run build FROM node:20-alpine AS runner WORKDIR /app ENV NODE_ENV=production RUN addgroup -g 1001 -S nodejs && adduser -S nextjs -u 1001 COPY --from=builder /app/public ./public COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./ COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static USER nextjs EXPOSE 3000 CMD ["node", "server.js"] ``` **Note:** For Next.js, add `output: 'standalone'` to your `next.config.js` to enable the standalone build mode used above. ### Python (Flask/FastAPI) Dockerfile ``` FROM python:3.12-slim AS builder WORKDIR /app # Install dependencies COPY requirements.txt . RUN pip install --no-cache-dir --user -r requirements.txt # Production stage FROM python:3.12-slim WORKDIR /app # Create non-root user RUN useradd -m -u 1001 appuser # Copy dependencies from builder COPY --from=builder /root/.local /home/appuser/.local # Copy application code COPY --chown=appuser:appuser . . USER appuser ENV PATH=/home/appuser/.local/bin:$PATH EXPOSE 8000 # For FastAPI with Uvicorn CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"] # For Flask with Gunicorn # CMD ["gunicorn", "--bind", "0.0.0.0:8000", "app:app"] ``` ### Go Dockerfile ``` FROM golang:1.22-alpine AS builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED=0 GOOS=linux go build -o /app/main . FROM alpine:3.19 RUN adduser -D -g '' appuser COPY --from=builder /app/main /app/main USER appuser EXPOSE 8080 CMD ["/app/main"] ``` Need help generating a Dockerfile? Try our [Dockerfile Generator](https://docker.servercompass.app/) — select your framework and get an optimized, production-ready Dockerfile instantly. ## Step 4: Build and Run Your Container With your Dockerfile ready, build and run your container: ``` # Navigate to your project directory cd /var/www/myapp # Build the Docker image docker build -t myapp:latest . # Run the container docker run -d \\ --name myapp \\ -p 3000:3000 \\ --restart unless-stopped \\ myapp:latest # Verify it's running docker ps # Check logs docker logs myapp ``` The `--restart unless-stopped` flag ensures your container automatically restarts after server reboots or crashes. Test your app by visiting `http://your-server-ip:3000`. ## Step 5: Docker Compose for Multi-Container Apps Docker Compose is where the magic happens for multi-container applications. Instead of running multiple `docker run` commands, you define everything in a single `docker-compose.yml` file. ### Basic Example: Node.js + PostgreSQL + Redis ``` # docker-compose.yml services: app: build: . ports: - "3000:3000" environment: - DATABASE_URL=postgresql://postgres:secretpassword@db:5432/myapp - REDIS_URL=redis://cache:6379 depends_on: db: condition: service_healthy cache: condition: service_started restart: unless-stopped db: image: postgres:16-alpine environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: secretpassword POSTGRES_DB: myapp volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 5s retries: 5 restart: unless-stopped cache: image: redis:7-alpine volumes: - redis_data:/data restart: unless-stopped volumes: postgres_data: redis_data: ``` ### Full Stack Example: Next.js + PostgreSQL + MinIO (S3-compatible storage) ``` # docker-compose.yml services: app: build: context: . dockerfile: Dockerfile ports: - "3000:3000" environment: - DATABASE_URL=postgresql://postgres:secretpassword@db:5432/myapp - S3_ENDPOINT=http://minio:9000 - S3_ACCESS_KEY=minioadmin - S3_SECRET_KEY=minioadmin - S3_BUCKET=uploads depends_on: db: condition: service_healthy restart: unless-stopped db: image: postgres:16-alpine environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: secretpassword POSTGRES_DB: myapp volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U postgres"] interval: 5s timeout: 5s retries: 5 restart: unless-stopped minio: image: minio/minio:latest command: server /data --console-address ":9001" ports: - "9000:9000" # API - "9001:9001" # Console environment: MINIO_ROOT_USER: minioadmin MINIO_ROOT_PASSWORD: minioadmin volumes: - minio_data:/data restart: unless-stopped volumes: postgres_data: minio_data: ``` ### Essential Docker Compose Commands ``` # Start all services (build if necessary) docker compose up -d # Start and rebuild images docker compose up -d --build # Stop all services docker compose down # Stop and remove volumes (careful - destroys data!) docker compose down -v # View logs for all services docker compose logs # View logs for specific service docker compose logs app # Follow logs in real-time docker compose logs -f # Restart a specific service docker compose restart app # Scale a service (if stateless) docker compose up -d --scale app=3 # Execute command in running container docker compose exec app sh # Pull latest images docker compose pull # View running services docker compose ps ``` ## Step 6: Persistent Data with Volumes Containers are ephemeral by default — when you remove a container, its data is gone. Volumes persist data outside the container lifecycle. ### Named Volumes (Recommended) ``` services: db: image: postgres:16-alpine volumes: - postgres_data:/var/lib/postgresql/data volumes: postgres_data: # Docker manages this volume automatically ``` Named volumes are managed by Docker and stored in `/var/lib/docker/volumes/`. They're portable, easy to backup, and survive container updates. ### Bind Mounts (For Specific Use Cases) ``` services: app: image: nginx:alpine volumes: # Mount local directory into container - ./nginx.conf:/etc/nginx/nginx.conf:ro - ./html:/usr/share/nginx/html:ro ``` Bind mounts link a specific path on your host to a path in the container. Use them for config files or when you need direct host filesystem access. ### Backing Up Volumes ``` # Backup a named volume to a tar file docker run --rm \\ -v postgres_data:/data \\ -v $(pwd):/backup \\ alpine tar cvf /backup/postgres_backup.tar /data # Restore a volume from backup docker run --rm \\ -v postgres_data:/data \\ -v $(pwd):/backup \\ alpine tar xvf /backup/postgres_backup.tar -C / ``` ## Step 7: Networking and Port Mapping Docker Compose automatically creates a network for your services. Containers can communicate using their service names as hostnames. ``` services: app: # Can connect to "db" and "cache" by name environment: - DATABASE_URL=postgresql://user:pass@db:5432/myapp - REDIS_URL=redis://cache:6379 db: image: postgres:16-alpine # No ports exposed - only accessible within Docker network cache: image: redis:7-alpine # No ports exposed - only accessible within Docker network ``` Only expose ports you need for external access. In the example above, only the app is accessible from outside — the database and cache are isolated to the internal Docker network. ### Port Mapping Explained ``` ports: - "3000:3000" # host:container - accessible from anywhere - "127.0.0.1:5432:5432" # Only accessible from localhost - "8080:80" # Map host port 8080 to container port 80 ``` ### Custom Networks ``` services: app: networks: - frontend - backend db: networks: - backend nginx: networks: - frontend networks: frontend: backend: ``` Custom networks let you isolate services. In this example, nginx can talk to app, and app can talk to db, but nginx cannot directly access db. ## Step 8: Traefik for Reverse Proxy and SSL Traefik is a modern reverse proxy that automatically discovers Docker containers and provisions SSL certificates from Let's Encrypt. It's the easiest way to get HTTPS running. For pre-built configurations, check out our [Traefik template](/features/domain-management) in the template gallery. ### Basic Traefik Setup Create a directory structure: ``` mkdir -p /opt/traefik cd /opt/traefik touch docker-compose.yml traefik.yml acme.json chmod 600 acme.json ``` Create the Traefik configuration: ``` # traefik.yml api: dashboard: true entryPoints: web: address: ":80" http: redirections: entryPoint: to: websecure scheme: https websecure: address: ":443" providers: docker: endpoint: "unix:///var/run/docker.sock" exposedByDefault: false network: traefik-public certificatesResolvers: letsencrypt: acme: email: your-email@example.com storage: /acme.json httpChallenge: entryPoint: web ``` ### Traefik Docker Compose ``` {`# docker-compose.yml (in /opt/traefik) services: traefik: image: traefik:v3.0 container_name: traefik restart: unless-stopped ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - ./traefik.yml:/traefik.yml:ro - ./acme.json:/acme.json networks: - traefik-public labels: # Enable Traefik dashboard - "traefik.enable=true" - "traefik.http.routers.dashboard.rule=Host(\`traefik.yourdomain.com\`)" - "traefik.http.routers.dashboard.service=api@internal" - "traefik.http.routers.dashboard.entrypoints=websecure" - "traefik.http.routers.dashboard.tls.certresolver=letsencrypt" - "traefik.http.routers.dashboard.middlewares=auth" # Basic auth for dashboard (generate with: htpasswd -nb admin password) - "traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$xxxxx" networks: traefik-public: external: true`} ``` Create the external network and start Traefik: ``` # Create the shared network docker network create traefik-public # Start Traefik cd /opt/traefik docker compose up -d ``` ### Connecting Your App to Traefik Update your application's `docker-compose.yml` to use Traefik: ``` {`# docker-compose.yml (your app) services: app: build: . restart: unless-stopped networks: - traefik-public - default labels: - "traefik.enable=true" - "traefik.http.routers.myapp.rule=Host(\`myapp.yourdomain.com\`)" - "traefik.http.routers.myapp.entrypoints=websecure" - "traefik.http.routers.myapp.tls.certresolver=letsencrypt" - "traefik.http.services.myapp.loadbalancer.server.port=3000" db: image: postgres:16-alpine # ... db config (no traefik labels needed) networks: traefik-public: external: true default:`} ``` That's it! Traefik automatically discovers your container, routes traffic to it, and provisions an SSL certificate. Visit `https://myapp.yourdomain.com`. ### Multiple Apps on Single Server ``` {`# App 1 - /opt/app1/docker-compose.yml services: app: build: . networks: - traefik-public labels: - "traefik.enable=true" - "traefik.http.routers.app1.rule=Host(\`app1.yourdomain.com\`)" - "traefik.http.routers.app1.entrypoints=websecure" - "traefik.http.routers.app1.tls.certresolver=letsencrypt" - "traefik.http.services.app1.loadbalancer.server.port=3000" networks: traefik-public: external: true # App 2 - /opt/app2/docker-compose.yml services: app: build: . networks: - traefik-public labels: - "traefik.enable=true" - "traefik.http.routers.app2.rule=Host(\`app2.yourdomain.com\`)" - "traefik.http.routers.app2.entrypoints=websecure" - "traefik.http.routers.app2.tls.certresolver=letsencrypt" - "traefik.http.services.app2.loadbalancer.server.port=8000" networks: traefik-public: external: true`} ``` Each app gets its own domain and SSL certificate, all routed through a single Traefik instance. ## Step 9: Container Management (Logs, Restart Policies, Health Checks) ### Restart Policies ``` services: app: restart: unless-stopped # Restart unless manually stopped # Other options: # restart: always # Always restart # restart: on-failure # Only restart on failure # restart: "no" # Never restart (default) ``` ### Health Checks ``` services: app: build: . healthcheck: test: ["CMD", "curl", "-f", "http://localhost:3000/health"] interval: 30s timeout: 10s retries: 3 start_period: 40s ``` Health checks let Docker know if your container is actually working. If a container becomes unhealthy, Docker can restart it automatically. ### Resource Limits ``` services: app: deploy: resources: limits: cpus: '0.5' memory: 512M reservations: cpus: '0.25' memory: 256M ``` ### Viewing and Managing Logs ``` # View last 100 lines docker compose logs --tail=100 app # Follow logs with timestamps docker compose logs -f --timestamps app # View logs since specific time docker compose logs --since 2h app # Configure log rotation in compose services: app: logging: driver: "json-file" options: max-size: "10m" max-file: "3" ``` ### Updating Containers ``` # Pull latest images and recreate containers docker compose pull docker compose up -d # Rebuild and update your app docker compose up -d --build # Remove old images docker image prune -f ``` ## Skip the CLI: Server Compass Visual Docker Deployment If you've followed this guide, you now understand how Docker deployment works on a VPS. But let's be honest — running these commands every time you deploy gets tedious fast. [Server Compass](/) automates everything you just learned into a visual interface: - **One-click Docker installation** — Server Compass detects if Docker is missing and installs it automatically. - **Visual Docker Compose editor** — Write and validate your compose files with syntax highlighting and error detection. - **Automatic Traefik setup** — SSL certificates provisioned automatically, zero configuration required. - **Framework detection** — Point Server Compass at your GitHub repo and it generates an optimized Dockerfile for 16+ frameworks. - **GitHub Actions builds** — Build Docker images on GitHub's infrastructure, not your VPS. Perfect for small servers. - **Real-time container monitoring** — See CPU, memory, and status for all containers in one dashboard. ![Server Compass container management dashboard showing running containers with CPU and memory metrics](/app-screenshots/feature-container-controls.jpg) Everything in this guide — Docker installation, Dockerfile creation, compose files, Traefik configuration, [container management](https://1devtool.com/features/docker-containers) — happens through a visual interface. No more SSH sessions, no more copy-pasting commands. For teams moving away from platforms like Railway, Server Compass provides a similar developer experience on your own VPS. Check out our [Railway alternative](/railway-alternative) comparison for more details. ## Frequently Asked Questions ### When should I use Kubernetes instead of Docker on VPS? Use Kubernetes when you need multi-node auto-scaling, automated failover across physical machines, or you're managing 50+ microservices. For most web apps, APIs, and side projects, Docker on a single VPS is simpler and more cost-effective. A well-configured $20/month VPS can handle more traffic than most apps will ever see. ### Should I use Docker Compose or Docker Swarm? Use Docker Compose for single-server deployments. Docker Swarm is designed for multi-node clusters and adds complexity you don't need for most projects. If you outgrow a single server, consider adding a second VPS with a load balancer before jumping to Swarm or Kubernetes. ### Why Traefik instead of Nginx? Traefik automatically discovers Docker containers and provisions SSL certificates with zero configuration. With Nginx, you manually edit config files and run Certbot for each domain. For Docker-based deployments, Traefik is significantly easier to maintain. ### How do I secure my Docker containers? Run containers as non-root users (shown in our Dockerfile examples), don't expose unnecessary ports, keep images updated, use secrets for sensitive data instead of environment variables, and scan images for vulnerabilities with `docker scout` or Trivy. ### How do I update my containers without downtime? Use blue-green deployment: spin up a new container, verify it's healthy, then switch Traefik routing. Server Compass handles this automatically with its GitHub Actions integration. For manual deployments, run the new container on a different port, test it, then update Traefik labels. ### What's the best backup strategy for Docker volumes? Use the `docker run --rm -v volume:/data -v $(pwd):/backup alpine tar` pattern shown earlier to create tarball backups. For databases, prefer native dump tools (pg\_dump, mysqldump) for consistent backups. Store backups in S3-compatible storage like Backblaze B2 or Cloudflare R2. ### How much VPS resources do I need? For most web applications: 2GB RAM minimum, 4GB recommended. Database containers (PostgreSQL, MySQL) benefit from more RAM. CPU is usually less critical — 2 vCPUs handles most workloads. Start small and scale up based on actual usage monitoring. ### Can I run multiple apps on one VPS? Yes. Use Traefik as shown in this guide to route different domains to different containers. A single VPS can easily run 10+ applications if they're not all resource-intensive. Monitor with `docker stats` and upgrade when needed. ## Conclusion Deploying Docker containers to a VPS without Kubernetes is straightforward once you understand the fundamentals. Docker handles containerization, Docker Compose orchestrates multi-container apps, and Traefik provides automatic SSL and routing. This stack scales from side projects to production workloads handling millions of requests. When you do outgrow a single VPS, you can add more servers behind a load balancer — still without Kubernetes. For teams that want this power without the CLI complexity, [Server Compass](/) wraps everything in a visual interface. One-time $29 purchase, no subscription, deploy unlimited apps to unlimited servers. Happy deploying! --- **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. 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. --- ## Deploy Express.js App to VPS (Step-by-Step Guide) Source: https://servercompass.app/blog/deploy-expressjs-app-to-vps-guide Published: 2026-03-06 Tags: expressjs, nodejs, vps-deploy, tutorials, self-hosted, docker, pm2 Learn how to deploy your Express.js application to a VPS step by step. This comprehensive guide covers production preparation, PM2 process management, Nginx reverse proxy, SSL certificates, firewall configuration, and a Docker alternative. Express.js powers millions of Node.js applications — from REST APIs to full-stack web apps. It's fast, flexible, and developer-friendly. But when it's time to deploy your Express app to a VPS, the simplicity ends and the complexity begins. SSH keys, Node.js installation, process management, reverse proxies, SSL certificates, firewall rules — what should be a straightforward deployment becomes a multi-hour ordeal. And if you get something wrong, your app crashes at 3 AM with no automatic restart. This guide walks you through every step of deploying an Express.js application to a VPS. You'll learn the manual approach (so you understand what's happening under the hood), plus a Docker alternative and the easy way using [Server Compass](/) for visual deployment. ## Why Deploy Express.js on a VPS? Before diving in, let's address why you might choose a VPS over managed platforms like Heroku, Render, or Railway: - **Cost savings** — A $5-10/month VPS can host multiple Express apps that would cost $50-100/month on PaaS platforms. See our [Vercel pricing breakdown](/blog/vercel-pricing-explained-hidden-costs) and [Render pricing analysis](/blog/render-pricing-is-it-worth-it) for real numbers. - **Full control** — Install any npm package, use any Node.js version, configure memory limits, and customize everything without platform restrictions. - **No cold starts** — Unlike serverless platforms, your Express app runs continuously with instant response times. - **Data sovereignty** — Your data stays on your server, in your chosen region, under your control. - **Learning experience** — Understanding server deployment makes you a better developer and helps you debug production issues. If you're building a serious project — an API backend, a SaaS application, or a production web app — deploying to your own VPS is often the most cost-effective and flexible choice. ## Prerequisites Before starting, make sure you have: - **A VPS** — Any provider works: DigitalOcean, Hetzner, Linode, Vultr, or AWS Lightsail. Ubuntu 22.04 or 24.04 LTS is recommended. A $5-10/month instance with 1GB RAM is sufficient for most Express apps. - **A domain name** — Point your domain's A record to your VPS IP address. This is required for SSL certificates. - **SSH access** — You should have either password or SSH key access to your server. Key-based authentication is more secure. - **An Express.js application** — Your app should be ready for production with a clear start command (usually `npm start` or `node app.js`). - **Git repository** — Your code should be in a Git repository (GitHub, GitLab, or Bitbucket) for easy deployment and updates. ## Step 1: Prepare Your Express App for Production Before deploying, ensure your Express application follows production best practices. These changes make your app more secure, stable, and easier to manage on a VPS. ### Use Environment Variables Never hardcode sensitive values like database URLs, API keys, or secrets. Use environment variables and the `dotenv` package: ``` {`// app.js or index.js require('dotenv').config(); const express = require('express'); const app = express(); const PORT = process.env.PORT || 3000; const NODE_ENV = process.env.NODE_ENV || 'development'; const DATABASE_URL = process.env.DATABASE_URL; app.listen(PORT, () => { console.log(\`Server running in \$ mode on port \$\`); });`} ``` Create a `.env.example` file (committed to Git) showing required variables, and a `.env` file (in `.gitignore`) with actual values: ``` # .env.example - commit this to your repository PORT=3000 NODE_ENV=production DATABASE_URL= JWT_SECRET= API_KEY= ``` ### Separate Production Dependencies Keep development dependencies separate in your `package.json`. On the server, you'll install only production dependencies with `npm ci --production`: ``` { "name": "my-express-app", "version": "1.0.0", "scripts": { "start": "node app.js", "dev": "nodemon app.js" }, "dependencies": { "express": "^4.18.2", "dotenv": "^16.3.1", "cors": "^2.8.5", "helmet": "^7.1.0" }, "devDependencies": { "nodemon": "^3.0.2" } } ``` ### Add Security Middleware Install and configure security middleware before deploying. At minimum, use `helmet` for HTTP headers and `cors` for cross-origin requests: ``` const express = require('express'); const helmet = require('helmet'); const cors = require('cors'); const app = express(); // Security headers app.use(helmet()); // CORS configuration app.use(cors({ origin: process.env.ALLOWED_ORIGINS?.split(',') || '*', credentials: true })); // Parse JSON bodies app.use(express.json({ limit: '10mb' })); // Trust proxy (required behind Nginx) app.set('trust proxy', 1); ``` ### Add a Health Check Endpoint A health check endpoint lets PM2, load balancers, and monitoring tools verify your app is running: ``` app.get('/health', (req, res) => { res.status(200).json({ status: 'healthy', timestamp: new Date().toISOString(), uptime: process.uptime() }); }); ``` ## Step 2: Connect to Your VPS via SSH Open your terminal and connect to your VPS. Replace `your-server-ip` with your actual VPS IP address: ``` # Connect with password (you'll be prompted) ssh root@your-server-ip # Or connect with SSH key ssh -i ~/.ssh/your-key root@your-server-ip ``` First time connecting? You'll see a fingerprint warning. Type `yes` to add the server to your known hosts. ### Create a Deploy User (Recommended) Running applications as root is a security risk. Create a dedicated user for deployments: ``` # Create a new user adduser deploy # Add to sudo group usermod -aG sudo deploy # Switch to the new user su - deploy ``` For future connections, use `ssh deploy@your-server-ip`. ## Step 3: Install Node.js The recommended way to install Node.js on Ubuntu is using NodeSource or nvm (Node Version Manager). We'll use NodeSource for a system-wide installation: ``` # Update package index sudo apt update && sudo apt upgrade -y # Install required packages sudo apt install -y curl git # Add NodeSource repository (Node.js 20 LTS) curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - # Install Node.js sudo apt install -y nodejs # Verify installation node --version # Should show v20.x.x npm --version # Should show 10.x.x ``` ### Alternative: Using nvm If you need multiple Node.js versions or want user-level installation, use nvm: ``` # Install nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # Reload shell configuration source ~/.bashrc # Install Node.js 20 LTS nvm install 20 nvm use 20 nvm alias default 20 ``` ## Step 4: Clone Your Repository and Install Dependencies Create a directory for your applications and clone your repository: ``` # Create apps directory mkdir -p ~/apps cd ~/apps # Clone your repository git clone https://github.com/yourusername/your-express-app.git cd your-express-app # Install production dependencies only npm ci --production ``` The `npm ci` command installs exact versions from `package-lock.json`, ensuring consistent deployments. The `--production` flag skips devDependencies. ### Private Repositories For private GitHub repositories, you'll need to set up authentication. The easiest method is a personal access token: ``` # Clone with token embedded (not recommended for shared servers) git clone https://YOUR_TOKEN@github.com/yourusername/your-express-app.git # Or configure Git credentials git config --global credential.helper store git clone https://github.com/yourusername/your-express-app.git # Enter your username and token when prompted ``` For better security, use SSH keys or a credentials manager. See our [GitHub deployment guide](/blog/how-to-connect-your-github-account-and-deploy-your-first-nextjs-app-to-your-vps) for detailed instructions. ## Step 5: Configure Environment Variables Create your production `.env` file on the server. Never commit this file to Git: ``` # Create .env file nano ~/apps/your-express-app/.env ``` Add your production environment variables: ``` PORT=3000 NODE_ENV=production DATABASE_URL=postgresql://user:password@localhost:5432/mydb JWT_SECRET=your-super-secret-key-change-this API_KEY=your-api-key ALLOWED_ORIGINS=https://yourdomain.com,https://www.yourdomain.com ``` Save and exit (`Ctrl+X`, then `Y`, then `Enter`). **Security tip:** Restrict file permissions so only the owner can read it: ``` chmod 600 ~/apps/your-express-app/.env ``` ## Step 6: Set Up PM2 for Process Management PM2 is the industry-standard process manager for Node.js applications. It keeps your app running, restarts it if it crashes, and provides logging and monitoring: ``` # Install PM2 globally sudo npm install -g pm2 ``` ### Create PM2 Ecosystem Configuration Instead of starting your app directly, create an ecosystem configuration file for better control. Create `ecosystem.config.js` in your project root: ``` // ecosystem.config.js module.exports = { apps: [ { name: 'my-express-app', script: 'app.js', instances: 'max', // Use all available CPU cores exec_mode: 'cluster', // Enable cluster mode for load balancing env: { NODE_ENV: 'development', PORT: 3000 }, env_production: { NODE_ENV: 'production', PORT: 3000 }, // Restart configuration max_memory_restart: '500M', // Restart if memory exceeds 500MB restart_delay: 3000, // Wait 3 seconds between restarts max_restarts: 10, // Maximum restart attempts min_uptime: '10s', // Minimum uptime to consider "started" // Logging log_file: '/var/log/pm2/my-express-app.log', error_file: '/var/log/pm2/my-express-app-error.log', out_file: '/var/log/pm2/my-express-app-out.log', merge_logs: true, log_date_format: 'YYYY-MM-DD HH:mm:ss Z', // Monitoring watch: false, // Don't watch files in production ignore_watch: ['node_modules', 'logs', '.git'], } ] }; ``` ### Start Your Application with PM2 ``` # Navigate to your app directory cd ~/apps/your-express-app # Create log directory sudo mkdir -p /var/log/pm2 sudo chown -R $USER:$USER /var/log/pm2 # Start the application pm2 start ecosystem.config.js --env production # Check status pm2 status # View logs pm2 logs my-express-app # Monitor in real-time pm2 monit ``` ### Configure PM2 to Start on Boot This ensures your app automatically restarts after a server reboot: ``` # Generate startup script pm2 startup systemd # Copy and run the command it outputs (will look like): # sudo env PATH=$PATH:/usr/bin pm2 startup systemd -u deploy --hp /home/deploy # Save current process list pm2 save ``` ### Essential PM2 Commands ``` # Restart application pm2 restart my-express-app # Reload with zero downtime (cluster mode) pm2 reload my-express-app # Stop application pm2 stop my-express-app # Delete from PM2 pm2 delete my-express-app # View detailed info pm2 describe my-express-app # Clear logs pm2 flush ``` ## Step 7: Configure Nginx as a Reverse Proxy Nginx sits in front of your Express app, handling SSL termination, static file serving, compression, and load balancing. It's the industry-standard setup for Node.js applications. ``` # Install Nginx sudo apt install -y nginx # Start and enable Nginx sudo systemctl start nginx sudo systemctl enable nginx ``` ### Create Nginx Configuration Create a configuration file for your domain: ``` sudo nano /etc/nginx/sites-available/your-express-app ``` Add the following configuration: ``` # Upstream for Express app (supports multiple instances) upstream express_backend { server 127.0.0.1:3000; keepalive 64; } server { listen 80; server_name yourdomain.com www.yourdomain.com; # Redirect HTTP to HTTPS (will be handled by Certbot) location / { return 301 https://$server_name$request_uri; } } server { listen 443 ssl http2; server_name yourdomain.com www.yourdomain.com; # SSL certificates (will be added by Certbot) # ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; # ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # Security headers add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; # Gzip compression gzip on; gzip_vary on; gzip_min_length 1024; gzip_types text/plain text/css text/xml text/javascript application/javascript application/json application/xml; # Proxy settings for Express location / { proxy_pass http://express_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; proxy_read_timeout 300s; proxy_connect_timeout 75s; } # Static files (if serving from Express) location /static/ { alias /home/deploy/apps/your-express-app/public/; expires 30d; add_header Cache-Control "public, immutable"; } # Health check endpoint (for monitoring) location /health { proxy_pass http://express_backend; proxy_http_version 1.1; proxy_set_header Host $host; access_log off; } # Deny access to hidden files location ~ /\\. { deny all; } } ``` ### Enable the Configuration ``` # Create symbolic link to enable the site sudo ln -s /etc/nginx/sites-available/your-express-app /etc/nginx/sites-enabled/ # Remove default site (optional) sudo rm /etc/nginx/sites-enabled/default # Test configuration syntax sudo nginx -t # If test passes, reload Nginx sudo systemctl reload nginx ``` ## Step 8: Set Up SSL with Certbot (Let's Encrypt) Free SSL certificates from Let's Encrypt are essential for any production website. Certbot automates the entire process: ``` # Install Certbot and Nginx plugin sudo apt install -y certbot python3-certbot-nginx # Obtain and install certificate sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com ``` Certbot will ask for your email address and whether to redirect HTTP to HTTPS. Choose to redirect for best security. ### Automatic Certificate Renewal Certbot sets up automatic renewal via a systemd timer. Verify it's active: ``` # Check timer status sudo systemctl status certbot.timer # Test renewal process sudo certbot renew --dry-run ``` Certificates renew automatically 30 days before expiration. ## Step 9: Configure UFW Firewall Secure your server by allowing only necessary incoming traffic: ``` # Install UFW (usually pre-installed on Ubuntu) sudo apt install -y ufw # Allow SSH (IMPORTANT: do this first to avoid lockout!) sudo ufw allow OpenSSH # Allow HTTP and HTTPS sudo ufw allow 'Nginx Full' # Enable the firewall sudo ufw enable # Check status sudo ufw status verbose ``` **Important:** Always allow SSH before enabling UFW, or you'll lock yourself out of the server. ### Additional Security (Optional) For enhanced security, consider installing Fail2ban to block brute-force attacks: ``` # Install Fail2ban sudo apt install -y fail2ban # Start and enable sudo systemctl start fail2ban sudo systemctl enable fail2ban ``` See our [Fail2ban feature guide](/features/fail2ban) for configuration options. ## Deploying Updates When you push changes to your repository, here's how to deploy them: ``` # SSH into your server ssh deploy@your-server-ip # Navigate to your app cd ~/apps/your-express-app # Pull latest changes git pull origin main # Install any new dependencies npm ci --production # Reload with zero downtime (cluster mode) pm2 reload my-express-app # Or restart (if not using cluster mode) pm2 restart my-express-app ``` ### Automated Deployment Script Create a deployment script to automate these steps: ``` #!/bin/bash # deploy.sh set -e # Exit on any error APP_DIR=~/apps/your-express-app APP_NAME=my-express-app echo "Deploying $APP_NAME..." cd $APP_DIR echo "Pulling latest changes..." git pull origin main echo "Installing dependencies..." npm ci --production echo "Reloading application..." pm2 reload $APP_NAME echo "Deployment complete!" pm2 status $APP_NAME ``` Make it executable and run: ``` chmod +x deploy.sh ./deploy.sh ``` ## Docker Alternative: Containerized Deployment Docker provides consistent deployments across environments. Here's how to containerize your Express app: ### Create a Dockerfile ``` # Dockerfile FROM node:20-alpine AS builder WORKDIR /app # Copy package files COPY package*.json ./ # Install dependencies RUN npm ci --production # Copy application code COPY . . # Production image FROM node:20-alpine WORKDIR /app # Create non-root user RUN addgroup -g 1001 -S nodejs && \\ adduser -S express -u 1001 # Copy from builder COPY --from=builder --chown=express:nodejs /app/node_modules ./node_modules COPY --from=builder --chown=express:nodejs /app . # Switch to non-root user USER express # Expose port EXPOSE 3000 # Health check HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \\ CMD wget --no-verbose --tries=1 --spider http://localhost:3000/health || exit 1 # Start application CMD ["node", "app.js"] ``` ### Create docker-compose.yml ``` # docker-compose.yml version: '3.8' services: express-app: build: . container_name: my-express-app restart: unless-stopped ports: - "3000:3000" environment: - NODE_ENV=production - PORT=3000 env_file: - .env networks: - app-network healthcheck: test: ["CMD", "wget", "--no-verbose", "--tries=1", "--spider", "http://localhost:3000/health"] interval: 30s timeout: 10s retries: 3 start_period: 10s networks: app-network: driver: bridge ``` ### Deploy with Docker ``` # Build and start containers docker compose up -d --build # View logs docker compose logs -f # Stop containers docker compose down # Rebuild and deploy updates docker compose up -d --build ``` ### Nginx with Docker Update your Nginx proxy\_pass to point to the Docker container: ``` upstream express_backend { server 127.0.0.1:3000; keepalive 64; } ``` The rest of the Nginx configuration remains the same. For a complete Docker + Nginx + SSL setup, see our [FastAPI Docker deployment guide](/blog/deploy-python-fastapi-on-vps-with-docker) which uses a similar architecture. ## The Easy Way: Deploy with Server Compass ![Server Compass framework detection showing Express.js project](/app-screenshots/feature-framework-detect.jpg) Everything above works, but it's a lot of manual configuration. If you're deploying multiple apps or want to skip the terminal entirely, [Server Compass](/) automates the entire process. ### What Server Compass Does For You - **Automatic framework detection** — Detects Express.js projects and configures the build automatically. See [framework detection](/features/framework-detection). - **Visual environment variables** — Manage `.env` files with the [.env Vault](/features/env-vault). No more nano editing. - **One-click deployments** — Connect your [GitHub repository](/features/github-repo-deploy) and deploy with a single click. - **Docker support** — The [Docker Stack Wizard](/features/docker-stack-wizard) handles containers, volumes, and networking. - **Process management** — Built-in PM2 integration with visual monitoring via [container status](/features/container-status). - **SSL certificates** — Automatic Let's Encrypt certificates with renewal. - **Deployment history** — View logs, rollback to previous versions, and track what's deployed with [deployment history](/features/deployment-history). ### Deploy Express.js with Server Compass 1. **Connect your VPS** — Add your server with SSH credentials in Server Compass 2. **Connect GitHub** — Authorize access to your repositories 3. **Select your Express repository** — Server Compass detects the framework automatically 4. **Configure environment variables** — Add your production `.env` values 5. **Deploy** — Click deploy and watch the real-time logs The entire process takes about 5 minutes instead of 2+ hours. And when you need to deploy updates, it's a single click. [Try Server Compass](/) — $29 one-time, no subscription. Includes all features, unlimited servers, and unlimited deployments. ## FAQ ### Which VPS provider should I use? For Express.js apps, any modern VPS works well. **Hetzner** offers the best price-to-performance ratio (starting at $4/month). **DigitalOcean** and **Linode** have excellent documentation and support. **Vultr** has the most global locations. For beginners, DigitalOcean's interface is the most user-friendly. ### How much RAM do I need? A basic Express.js API runs comfortably on 512MB-1GB RAM. For production apps with moderate traffic, 2GB is recommended. If you're running PM2 in cluster mode (multiple instances), calculate roughly 100-200MB per instance plus overhead. ### Should I use PM2 cluster mode? Yes, for production. Cluster mode runs multiple instances of your app across CPU cores, improving performance and enabling zero-downtime reloads. Set `instances: 'max'` in your ecosystem config, or specify a number like `instances: 2`. ### How do I handle WebSockets with Nginx? The Nginx configuration in this guide already supports WebSockets via the `Upgrade` and `Connection` headers. If you're using Socket.io, ensure sticky sessions are enabled for cluster mode (or use Redis adapter). ### Can I run multiple Express apps on one VPS? Absolutely. Run each app on a different port (3000, 3001, 3002, etc.) and create separate Nginx server blocks for each domain. PM2 handles multiple apps natively — just add more entries to your ecosystem config. ### What about databases? You can run PostgreSQL, MySQL, or MongoDB on the same VPS. See our guides for [self-hosted PostgreSQL](/blog/how-to-self-host-postgresql-on-your-vps) and [MongoDB templates](/templates/mongodb). For simplicity, consider Docker Compose to manage your Express app and database together. ### How do I set up CI/CD? Use GitHub Actions to automate deployments. Push to main, Actions runs tests, builds your app, and SSHs into your server to pull and restart. See our [GitHub Actions deployment guide](/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments) for a complete walkthrough. ### How do I monitor my Express app? PM2 provides built-in monitoring (`pm2 monit`). For more comprehensive monitoring, consider: - **PM2 Plus** — PM2's paid monitoring dashboard - **Server Compass** — Visual monitoring with [resource monitoring](/features/resource-monitoring) and [container logs](/features/container-logs) - **Uptime Kuma** — Self-hosted uptime monitoring (see [Uptime Kuma template](/templates/uptime-kuma)) ### How much does this all cost? A complete production setup costs approximately: - VPS: $5-10/month (Hetzner, DigitalOcean) - Domain: $10-15/year - SSL: Free (Let's Encrypt) - Server Compass (optional): $29 one-time Compare this to Heroku ($7-25/month per dyno), Render ($7+/month), or Railway (usage-based, often $20+/month). Self-hosting saves 50-80% annually while giving you full control. ## Conclusion Deploying Express.js to a VPS is straightforward once you understand the components: Node.js runtime, PM2 for process management, Nginx for reverse proxy and SSL, and UFW for security. The manual approach gives you complete control and helps you understand what's happening on your server. For production deployments where you want to save time and reduce errors, Docker provides consistent, reproducible builds. And if you want to skip the terminal entirely, [Server Compass](/) handles everything visually — from GitHub integration to PM2 management to SSL certificates. Ready to deploy? Pick the approach that fits your workflow: - **Learning or simple apps** — Follow the manual steps above - **Team deployments or microservices** — Use Docker + docker-compose - **Multiple apps or visual management** — [Try Server Compass](/) Questions about deploying Express.js? Check out our [video tutorials](/tutorials) or explore the [template gallery](/templates) for one-click deployments of popular stacks. --- **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'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. --- ## Deploy Laravel on VPS with Docker (Production Guide) Source: https://servercompass.app/blog/deploy-laravel-on-vps-with-docker Published: 2026-03-06 Tags: self-hosted, laravel, docker, vps-deploy, tutorials Complete guide to deploying Laravel on your VPS using Docker. Covers Dockerfile, docker-compose with MySQL and Redis, Nginx configuration, SSL, queue workers, scheduler, and automated backups for a production-ready setup. Laravel is one of the most popular PHP frameworks, powering everything from small blogs to enterprise applications. But deploying it to production? That's where many developers struggle. Managed platforms like Laravel Forge, Vapor, or Ploi cost $12–$39/month. Add database hosting, Redis, and storage, and you're looking at $50–$150/month for a modest application. Meanwhile, a $5 VPS from Hetzner or DigitalOcean can run your entire Laravel stack with plenty of headroom. This guide shows you how to deploy Laravel on your VPS using Docker, complete with MySQL, Redis, Nginx, SSL, queue workers, the scheduler, and automated backups. By the end, you'll have a production-ready setup that costs 80% less than managed alternatives. ## Prerequisites Before we start, make sure you have: - **A VPS** — Any Linux server with at least 1GB RAM. Recommended providers: Hetzner ($4/mo), DigitalOcean ($6/mo), Vultr ($5/mo), or Linode ($5/mo). - **A domain name** — Pointed to your VPS IP address via an A record. - **SSH access** — Root or sudo user access to your server. - **Docker and Docker Compose** — We'll cover installation if not already present. - **A Laravel project** — Either an existing project or a fresh `laravel new myapp`. ## Step 1: Prepare Laravel for Production Before containerizing your Laravel application, ensure it's ready for production. Open your `.env` file and update these settings: ``` APP_ENV=production APP_DEBUG=false APP_URL=https://yourdomain.com LOG_CHANNEL=stderr DB_CONNECTION=mysql DB_HOST=mysql DB_PORT=3306 DB_DATABASE=laravel DB_USERNAME=laravel DB_PASSWORD=your_secure_password CACHE_DRIVER=redis QUEUE_CONNECTION=redis SESSION_DRIVER=redis REDIS_HOST=redis REDIS_PASSWORD=null REDIS_PORT=6379 ``` Key changes for Docker: - **DB\_HOST=mysql** — Docker networking uses container names as hostnames. - **REDIS\_HOST=redis** — Same principle for Redis. - **LOG\_CHANNEL=stderr** — Logs go to Docker's logging system instead of files. - **APP\_DEBUG=false** — Never expose debug information in production. Also update `config/database.php` to ensure Redis uses the correct connection: ``` 'redis' => [ 'client' => env('REDIS_CLIENT', 'phpredis'), 'default' => [ 'host' => env('REDIS_HOST', '127.0.0.1'), 'password' => env('REDIS_PASSWORD'), 'port' => env('REDIS_PORT', 6379), 'database' => 0, ], 'cache' => [ 'host' => env('REDIS_HOST', '127.0.0.1'), 'password' => env('REDIS_PASSWORD'), 'port' => env('REDIS_PORT', 6379), 'database' => 1, ], ], ``` ## Step 2: Create the Dockerfile Create a `Dockerfile` in your Laravel project root. This multi-stage build optimizes for production by separating dependency installation from the final image: ``` # Stage 1: Build PHP dependencies FROM composer:2 AS composer WORKDIR /app COPY composer.json composer.lock ./ RUN composer install --no-dev --no-scripts --no-autoloader --prefer-dist COPY . . RUN composer dump-autoload --optimize --classmap-authoritative # Stage 2: Build frontend assets FROM node:20-alpine AS node WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build # Stage 3: Production image FROM php:8.3-fpm-alpine # Install system dependencies RUN apk add --no-cache \\ nginx \\ supervisor \\ libpng-dev \\ libjpeg-turbo-dev \\ freetype-dev \\ libzip-dev \\ oniguruma-dev \\ icu-dev \\ && docker-php-ext-configure gd --with-freetype --with-jpeg \\ && docker-php-ext-install -j$(nproc) \\ pdo_mysql \\ mbstring \\ exif \\ pcntl \\ bcmath \\ gd \\ zip \\ intl \\ opcache # Install Redis extension RUN apk add --no-cache --virtual .build-deps $PHPIZE_DEPS \\ && pecl install redis \\ && docker-php-ext-enable redis \\ && apk del .build-deps # Configure PHP for production COPY docker/php.ini /usr/local/etc/php/conf.d/custom.ini # Configure Nginx COPY docker/nginx.conf /etc/nginx/nginx.conf # Configure Supervisor COPY docker/supervisord.conf /etc/supervisor/conf.d/supervisord.conf # Set working directory WORKDIR /var/www/html # Copy application code COPY --from=composer /app/vendor ./vendor COPY --from=node /app/public/build ./public/build COPY . . # Set permissions RUN chown -R www-data:www-data /var/www/html \\ && chmod -R 755 /var/www/html/storage \\ && chmod -R 755 /var/www/html/bootstrap/cache # Create required directories RUN mkdir -p /var/log/supervisor \\ && mkdir -p /run/nginx EXPOSE 80 CMD ["/usr/bin/supervisord", "-c", "/etc/supervisor/conf.d/supervisord.conf"] ``` This Dockerfile: - Uses a multi-stage build to keep the final image small - Installs all required PHP extensions for Laravel - Includes Redis extension for caching and queues - Uses Supervisor to manage multiple processes (PHP-FPM, Nginx, queue workers) - Sets proper permissions for storage and cache directories ## Step 3: Docker Compose Configuration Create a `docker-compose.yml` file that orchestrates Laravel, MySQL, and Redis together. This is the complete production-ready configuration: ``` {`version: '3.8' services: app: build: context: . dockerfile: Dockerfile container_name: laravel-app restart: unless-stopped volumes: - ./storage:/var/www/html/storage - ./.env:/var/www/html/.env networks: - laravel depends_on: mysql: condition: service_healthy redis: condition: service_started labels: - "traefik.enable=true" - "traefik.http.routers.laravel.rule=Host(\`yourdomain.com\`)" - "traefik.http.routers.laravel.entrypoints=websecure" - "traefik.http.routers.laravel.tls.certresolver=letsencrypt" - "traefik.http.services.laravel.loadbalancer.server.port=80" mysql: image: mysql:8.0 container_name: laravel-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: \${DB_ROOT_PASSWORD:-rootpassword} MYSQL_DATABASE: \${DB_DATABASE:-laravel} MYSQL_USER: \${DB_USERNAME:-laravel} MYSQL_PASSWORD: \${DB_PASSWORD:-secret} volumes: - mysql_data:/var/lib/mysql - ./docker/mysql/init.sql:/docker-entrypoint-initdb.d/init.sql:ro networks: - laravel healthcheck: test: ["CMD", "mysqladmin", "ping", "-h", "localhost"] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine container_name: laravel-redis restart: unless-stopped command: redis-server --appendonly yes volumes: - redis_data:/data networks: - laravel queue: build: context: . dockerfile: Dockerfile container_name: laravel-queue restart: unless-stopped command: php artisan queue:work --sleep=3 --tries=3 --max-time=3600 volumes: - ./storage:/var/www/html/storage - ./.env:/var/www/html/.env networks: - laravel depends_on: mysql: condition: service_healthy redis: condition: service_started scheduler: build: context: . dockerfile: Dockerfile container_name: laravel-scheduler restart: unless-stopped command: sh -c "while true; do php artisan schedule:run --verbose --no-interaction & sleep 60; done" volumes: - ./storage:/var/www/html/storage - ./.env:/var/www/html/.env networks: - laravel depends_on: mysql: condition: service_healthy redis: condition: service_started networks: laravel: driver: bridge volumes: mysql_data: redis_data:`} ``` This configuration includes five services: - **app** — Your Laravel application with PHP-FPM and Nginx - **mysql** — MySQL 8.0 database with health checks and persistent storage. See our [MySQL template](/templates/mysql) for more options. - **redis** — Redis for caching, sessions, and queues. See our [Redis template](/templates/redis) for advanced configurations. - **queue** — Dedicated container for Laravel queue workers - **scheduler** — Dedicated container for Laravel's task scheduler You can also use our pre-built [Laravel template](/install/laravel) which includes all of this pre-configured and ready to deploy with one click. ## Step 4: Create Supporting Configuration Files Create a `docker` directory in your project root for configuration files. ### PHP Configuration (docker/php.ini) ``` [PHP] ; Production settings display_errors = Off display_startup_errors = Off error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT log_errors = On error_log = /dev/stderr ; Performance memory_limit = 256M max_execution_time = 60 max_input_time = 60 post_max_size = 100M upload_max_filesize = 100M ; OPcache opcache.enable = 1 opcache.memory_consumption = 128 opcache.interned_strings_buffer = 8 opcache.max_accelerated_files = 10000 opcache.validate_timestamps = 0 opcache.revalidate_freq = 0 opcache.save_comments = 1 ; Session session.cookie_httponly = 1 session.cookie_secure = 1 session.use_strict_mode = 1 ``` ### Nginx Configuration (docker/nginx.conf) ``` worker_processes auto; error_log /dev/stderr warn; pid /run/nginx.pid; events { worker_connections 1024; multi_accept on; use epoll; } http { include /etc/nginx/mime.types; default_type application/octet-stream; log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /dev/stdout main; sendfile on; tcp_nopush on; tcp_nodelay on; keepalive_timeout 65; types_hash_max_size 2048; # Gzip compression gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css text/xml application/json application/javascript application/xml application/xml+rss text/javascript application/x-font-ttf font/opentype image/svg+xml; server { listen 80 default_server; server_name _; root /var/www/html/public; index index.php; charset utf-8; # Security headers add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; location / { try_files $uri $uri/ /index.php?$query_string; } location = /favicon.ico { access_log off; log_not_found off; } location = /robots.txt { access_log off; log_not_found off; } error_page 404 /index.php; location ~ \\.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $realpath_root$fastcgi_script_name; include fastcgi_params; fastcgi_hide_header X-Powered-By; } # Deny access to hidden files location ~ /\\. { deny all; } # Cache static assets location ~* \\.(jpg|jpeg|png|gif|ico|css|js|woff|woff2|ttf|svg)$ { expires 30d; add_header Cache-Control "public, immutable"; } } } ``` Notice the `robots.txt` location block — this tells Nginx to serve your robots file efficiently. Need help creating one? Use our [free robots.txt generator](/tools/robots-txt-generator) to control how search engines and AI crawlers access your Laravel app. ### Supervisor Configuration (docker/supervisord.conf) ``` [supervisord] nodaemon=true logfile=/var/log/supervisor/supervisord.log pidfile=/var/run/supervisord.pid user=root [program:php-fpm] command=/usr/local/sbin/php-fpm -F autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 [program:nginx] command=/usr/sbin/nginx -g "daemon off;" autostart=true autorestart=true stdout_logfile=/dev/stdout stdout_logfile_maxbytes=0 stderr_logfile=/dev/stderr stderr_logfile_maxbytes=0 ``` ## Step 5: Connect to Your VPS SSH into your server and install Docker if it's not already present: ``` # Connect to your VPS ssh root@your-server-ip # Install Docker (if not installed) curl -fsSL https://get.docker.com | sh # Start Docker and enable on boot systemctl enable docker systemctl start docker # Verify installation docker --version docker compose version ``` Create a directory for your Laravel application: ``` mkdir -p /var/www/laravel cd /var/www/laravel ``` ## Step 6: Deploy with Docker Compose Transfer your Laravel project to the server. You can use Git, SCP, or rsync: ``` # Option 1: Clone from Git git clone https://github.com/yourusername/your-laravel-app.git . # Option 2: SCP from local machine scp -r ./your-laravel-app/* root@your-server-ip:/var/www/laravel/ # Option 3: rsync (recommended for updates) rsync -avz --exclude='vendor' --exclude='node_modules' \\ ./your-laravel-app/ root@your-server-ip:/var/www/laravel/ ``` Create your production `.env` file on the server: ``` cp .env.example .env nano .env # Edit with your production values ``` Build and start the containers: ``` # Build images docker compose build # Start containers in the background docker compose up -d # Check status docker compose ps # View logs docker compose logs -f ``` Run Laravel setup commands: ``` # Generate application key docker compose exec app php artisan key:generate # Run migrations docker compose exec app php artisan migrate --force # Cache configuration for performance docker compose exec app php artisan config:cache docker compose exec app php artisan route:cache docker compose exec app php artisan view:cache # Create storage symlink docker compose exec app php artisan storage:link ``` ## Step 7: Configure Nginx Reverse Proxy (Alternative to Traefik) If you prefer using a standalone Nginx reverse proxy instead of Traefik, install Nginx on your host and configure it: ``` # Install Nginx apt update && apt install -y nginx # Create site configuration nano /etc/nginx/sites-available/laravel ``` Add this configuration: ``` server { listen 80; server_name yourdomain.com www.yourdomain.com; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; proxy_read_timeout 300; proxy_connect_timeout 300; # Important for Laravel trusted proxies proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port $server_port; } } ``` Enable the site and test the configuration: ``` # Enable site ln -s /etc/nginx/sites-available/laravel /etc/nginx/sites-enabled/ # Remove default site rm /etc/nginx/sites-enabled/default # Test configuration nginx -t # Reload Nginx systemctl reload nginx ``` Update your docker-compose.yml to expose port 8080 instead of using Traefik labels: ``` app: # ... other settings ... ports: - "127.0.0.1:8080:80" # Remove or comment out Traefik labels ``` ## Step 8: SSL Setup with Let's Encrypt Secure your application with a free SSL certificate from Let's Encrypt: ``` # Install Certbot apt install -y certbot python3-certbot-nginx # Obtain SSL certificate certbot --nginx -d yourdomain.com -d www.yourdomain.com # Certbot will automatically: # - Obtain the certificate # - Update your Nginx configuration # - Set up automatic renewal ``` Verify automatic renewal is configured: ``` # Test renewal certbot renew --dry-run # Check the renewal timer systemctl status certbot.timer ``` Update Laravel's trusted proxies in `app/Http/Middleware/TrustProxies.php`: ``` command('sanctum:prune-expired --hours=24') ->daily(); // Example: Send daily digest emails $schedule->command('emails:send-digest') ->dailyAt('08:00') ->timezone('America/New_York'); // Example: Clear old cache weekly $schedule->command('cache:prune-stale-tags') ->weekly(); // Example: Database backup daily $schedule->command('backup:run') ->dailyAt('02:00') ->onOneServer(); // Example: Telescope pruning $schedule->command('telescope:prune --hours=48') ->daily(); } protected function commands(): void { $this->load(__DIR__.'/Commands'); require base_path('routes/console.php'); } } ``` Verify the scheduler is running: ``` # View scheduler logs docker compose logs -f scheduler # Run schedule manually to test docker compose exec app php artisan schedule:run ``` ## Step 11: Automated Backups Set up automated backups for your database and uploaded files. Install the Spatie backup package: ``` # Install backup package docker compose exec app composer require spatie/laravel-backup # Publish configuration docker compose exec app php artisan vendor:publish \\ --provider="Spatie\\Backup\\BackupServiceProvider" ``` Configure `config/backup.php` for your needs: ``` 'backup' => [ 'name' => env('APP_NAME', 'laravel-backup'), 'source' => [ 'files' => [ 'include' => [ base_path(), ], 'exclude' => [ base_path('vendor'), base_path('node_modules'), storage_path('logs'), ], ], 'databases' => ['mysql'], ], 'destination' => [ 'disks' => ['s3'], // or 'local' ], ], 'notifications' => [ 'mail' => [ 'to' => 'your-email@example.com', ], ], ``` Add the backup command to your scheduler: ``` // In app/Console/Kernel.php $schedule->command('backup:run')->dailyAt('02:00'); $schedule->command('backup:clean')->dailyAt('03:00'); ``` For S3-compatible storage (AWS S3, Backblaze B2, Cloudflare R2), add the S3 driver: ``` # Install S3 driver docker compose exec app composer require league/flysystem-aws-s3-v3 "^3.0" ``` Configure your S3 credentials in `.env`: ``` AWS_ACCESS_KEY_ID=your-key AWS_SECRET_ACCESS_KEY=your-secret AWS_DEFAULT_REGION=us-east-1 AWS_BUCKET=your-bucket-name AWS_ENDPOINT=https://s3.us-east-1.amazonaws.com # or Backblaze/R2 endpoint ``` ## The Easy Way: Deploy Laravel with Server Compass All of the above takes 2–4 hours for a first-time setup. With [Server Compass](/), you can deploy Laravel in under 5 minutes. Here's how: 1. **Connect your VPS** — Add your server once with SSH credentials. Server Compass auto-installs Docker if needed. 2. **Select the Laravel template** — Our [Laravel template](/install/laravel) includes the complete stack: PHP-FPM, Nginx, MySQL, Redis, queue workers, and scheduler. 3. **Configure environment variables** — Use the visual [.env Vault](/features/env-vault) to set your database credentials, app URL, and other settings. 4. **Deploy** — One click and your Laravel app is live with SSL, automatic restarts, and health monitoring. ![Server Compass template gallery showing Laravel and other one-click deployment templates](/app-screenshots/feature-templates.jpg) What you get with Server Compass: - [100+ one-click templates](/features/template-deployment) including [Laravel](/install/laravel), [MySQL](/templates/mysql), and [Redis](/templates/redis) - [Visual Docker Compose editor](/features/docker-stack-wizard) with validation - [Real-time container logs](/features/container-logs) and [resource monitoring](/features/resource-monitoring) - [Automated backups](/features/server-backups) to S3-compatible storage - [Free SSL certificates](/features/auto-ssl) via Let's Encrypt - [GitHub Actions CI/CD](/features/github-actions) for automatic deployments - [Built-in database admin](/features/db-admin) with SQL editor **Server Compass is $29 one-time. No subscription.** That's less than one month of Laravel Forge, and you own it forever. ## Frequently Asked Questions ### What are the minimum VPS specs for Laravel with Docker? For a small-to-medium Laravel application with MySQL and Redis, you need at least: - **RAM:** 1GB minimum, 2GB recommended - **CPU:** 1 vCPU minimum, 2 vCPUs for better performance - **Storage:** 20GB SSD minimum A $5–$6/month VPS from Hetzner, DigitalOcean, or Vultr handles most Laravel applications comfortably. ### Why use Docker instead of traditional LEMP? Docker provides several advantages over a traditional LEMP (Linux, Nginx, MySQL, PHP) stack: - **Consistency:** Same environment in development and production - **Isolation:** Each service runs in its own container - **Portability:** Move your stack to any Docker host - **Scalability:** Scale individual services independently - **Easy updates:** Update PHP or MySQL versions with a single line change ### How do I update my Laravel application? For code updates: ``` # Pull latest code git pull origin main # Rebuild and restart containers docker compose build app docker compose up -d app # Run migrations docker compose exec app php artisan migrate --force # Clear caches docker compose exec app php artisan optimize:clear docker compose exec app php artisan config:cache docker compose exec app php artisan route:cache docker compose exec app php artisan view:cache ``` ### How do I achieve zero-downtime deployments? Use a blue-green deployment strategy with Traefik or a reverse proxy. Server Compass provides built-in [zero-downtime deployments via GitHub Actions](/features/github-actions) that handle this automatically. ### How do I view Laravel logs? With `LOG_CHANNEL=stderr`, logs go to Docker: ``` # View all logs docker compose logs -f app # View last 100 lines docker compose logs --tail=100 app # View queue worker logs docker compose logs -f queue ``` ### How do I handle file uploads and storage? The docker-compose.yml mounts `./storage` as a volume, so uploaded files persist outside the container. For production, consider using S3 or S3-compatible storage: ``` # .env FILESYSTEM_DISK=s3 AWS_ACCESS_KEY_ID=your-key AWS_SECRET_ACCESS_KEY=your-secret AWS_DEFAULT_REGION=us-east-1 AWS_BUCKET=your-bucket ``` ### Can I run multiple Laravel apps on one VPS? Yes. Use different container names and either: - Different ports with Nginx reverse proxy routing by domain - Traefik with different hostnames in labels ## Conclusion Deploying Laravel on a VPS with Docker gives you full control over your infrastructure at a fraction of the cost of managed platforms. The setup we've covered includes: - Production-optimized Dockerfile with multi-stage builds - Docker Compose orchestrating Laravel, MySQL, Redis, queues, and scheduler - Nginx configuration with security headers and caching - SSL via Let's Encrypt - Automated backups to S3-compatible storage For a faster deployment experience, try [Server Compass](/). Deploy Laravel with MySQL, Redis, and all the production essentials in under 5 minutes. No SSH required, no manual configuration, and built-in monitoring for peace of mind. [Download Server Compass](/) — $29 one-time, unlimited servers, no subscription. --- **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'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. --- ## Deploy Next.js to VPS: Complete Guide (2026) Source: https://servercompass.app/blog/deploy-nextjs-to-vps-complete-guide Published: 2026-03-06 Tags: nextjs, deployment, docker, vps-deploy, tutorials Learn how to deploy Next.js applications to your own VPS with PM2, Docker, Nginx, and SSL. A comprehensive guide covering standalone mode, reverse proxy configuration, and environment variables — plus the easy way with Server Compass. Deploying Next.js to your own VPS gives you complete control over your infrastructure, predictable costs, and the freedom to scale on your terms. While Vercel offers a frictionless deployment experience, it comes with usage-based pricing that can quickly spiral out of control as your application grows. This guide walks you through every step of deploying a Next.js application to a VPS, from preparing your app for production to configuring SSL certificates. Whether you choose PM2 for simplicity or Docker for containerization, you'll have a production-ready deployment by the end. ## Why Self-Host Next.js Instead of Vercel? Vercel is the company behind Next.js, and their platform is optimized for it. So why would you deploy elsewhere? Here are the most common reasons developers make the switch: - **Cost predictability** — Vercel's free tier is generous for hobby projects, but production apps quickly hit bandwidth limits, function invocation caps, and image optimization quotas. A $5–$10 VPS gives you unlimited bandwidth and no per-request fees. - **No vendor lock-in** — Vercel-specific features like Edge Functions, Middleware edge runtime, and ISR caching work differently (or not at all) on other platforms. Self-hosting keeps your app portable. - **Data sovereignty** — Your server, your region, your rules. No data processing agreements with third parties, no questions about where your users' data is stored. - **Full server access** — Need to run background jobs, connect to a local database, or install system dependencies? A VPS gives you root access to do whatever you need. - **Custom caching strategies** — Implement your own CDN, use Varnish, or configure Redis caching exactly how you want it. For a deeper comparison, see our [Server Compass vs Vercel comparison](/compare/vercel) and the [Vercel alternative](/vercel-alternative) page. ## Prerequisites Before you begin, make sure you have: - **A VPS** — Any provider works: Hetzner, DigitalOcean, Linode, Vultr, or AWS Lightsail. We recommend at least 1 GB RAM and 1 vCPU for small Next.js apps. Ubuntu 22.04 or 24.04 is ideal. - **A domain name** — Pointed to your server's IP address with an A record. - **SSH access** — Root or sudo access to your server. - **A Next.js application** — Either a new project or an existing one you want to deploy. - **Git repository** — Your code should be in GitHub, GitLab, or another Git hosting service for easy deployment. ## Step 1: Prepare Your Next.js App for Production Next.js has a special `standalone` output mode that creates a minimal production bundle. This is essential for VPS deployment because it copies only the necessary files and dependencies. Open your `next.config.js` (or `next.config.ts`) and add the output configuration: ``` // next.config.js /** @type {import('next').NextConfig} */ const nextConfig = { output: 'standalone', } module.exports = nextConfig ``` For TypeScript projects using `next.config.ts`: ``` // next.config.ts import type { NextConfig } from 'next' const nextConfig: NextConfig = { output: 'standalone', } export default nextConfig ``` The `standalone` output mode: - Creates a self-contained `.next/standalone` folder - Copies only production dependencies (not devDependencies) - Generates a `server.js` file that runs without `next start` - Reduces deployment size by 80–90% compared to copying `node_modules` After adding this configuration, run a production build locally to verify it works: ``` npm run build ``` Check that `.next/standalone` exists and contains `server.js`. ## Step 2: Connect to Your VPS SSH into your server using the credentials from your VPS provider: ``` ssh root@your-server-ip ``` If you're using a non-root user with sudo privileges: ``` ssh username@your-server-ip ``` For better security, set up SSH key authentication instead of password login. See our [SSH config generator](/tools/ssh-config-generator) for help creating SSH configuration files. ## Step 3: Install Node.js and Dependencies We recommend using `nvm` (Node Version Manager) to install Node.js. This lets you easily switch between Node versions and keeps your system Node separate from your application. ``` # Update system packages sudo apt update && sudo apt upgrade -y # Install curl if not present sudo apt install -y curl # Install nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash # Load nvm (or restart your terminal) source ~/.bashrc # Install the latest LTS version of Node.js nvm install --lts # Verify installation node --version npm --version ``` Install PM2 globally for process management: ``` npm install -g pm2 ``` PM2 keeps your Next.js app running, restarts it on crashes, and provides logging and monitoring. It's the standard for running Node.js applications in production. ## Step 4: Clone and Build Your Next.js App Create a directory for your applications and clone your repository: ``` # Create apps directory mkdir -p ~/apps cd ~/apps # Clone your repository git clone https://github.com/yourusername/your-nextjs-app.git cd your-nextjs-app # Install dependencies npm ci # Build the application npm run build ``` The `npm ci` command is preferred over `npm install` for production because it installs exact versions from `package-lock.json` and is faster. After the build completes, you need to copy the static files to the standalone folder: ``` # Copy static files to standalone cp -r .next/static .next/standalone/.next/ cp -r public .next/standalone/ ``` This is necessary because the standalone output doesn't include the `static` folder or `public` directory by default. ## Step 5: Run with PM2 (Standalone Mode) Create a PM2 ecosystem configuration file for better process management: ``` // ecosystem.config.js module.exports = { apps: [ { name: 'nextjs-app', script: '.next/standalone/server.js', cwd: '/root/apps/your-nextjs-app', instances: 'max', exec_mode: 'cluster', env: { NODE_ENV: 'production', PORT: 3000, HOSTNAME: '0.0.0.0', }, env_production: { NODE_ENV: 'production', PORT: 3000, HOSTNAME: '0.0.0.0', }, // Restart if memory exceeds 500MB max_memory_restart: '500M', // Log configuration error_file: '/root/apps/your-nextjs-app/logs/error.log', out_file: '/root/apps/your-nextjs-app/logs/out.log', log_date_format: 'YYYY-MM-DD HH:mm:ss Z', // Graceful restart kill_timeout: 5000, wait_ready: true, listen_timeout: 10000, }, ], } ``` Create the logs directory and start the application: ``` # Create logs directory mkdir -p ~/apps/your-nextjs-app/logs # Start with PM2 cd ~/apps/your-nextjs-app pm2 start ecosystem.config.js --env production # Save the PM2 process list pm2 save # Configure PM2 to start on boot pm2 startup ``` The `pm2 startup` command will output a command you need to run with sudo. Copy and execute it to enable automatic startup. Useful PM2 commands: ``` pm2 status # View all processes pm2 logs nextjs-app # View logs pm2 restart nextjs-app # Restart the app pm2 stop nextjs-app # Stop the app pm2 delete nextjs-app # Remove from PM2 ``` Use our [PM2 config generator](/tools/pm2-config-generator) to create custom ecosystem configurations. ## Step 6: Docker Alternative (with Dockerfile Example) Docker provides better isolation, reproducibility, and makes deployment more consistent across environments. Here's a production-ready Dockerfile for Next.js: ``` # Dockerfile FROM node:20-alpine AS base # Install dependencies only when needed FROM base AS deps RUN apk add --no-cache libc6-compat WORKDIR /app # Install dependencies based on the preferred package manager COPY package.json package-lock.json* ./ RUN npm ci # Rebuild the source code only when needed FROM base AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . # Disable telemetry during build ENV NEXT_TELEMETRY_DISABLED=1 RUN npm run build # Production image, copy all the files and run next FROM base AS runner WORKDIR /app ENV NODE_ENV=production ENV NEXT_TELEMETRY_DISABLED=1 RUN addgroup --system --gid 1001 nodejs RUN adduser --system --uid 1001 nextjs COPY --from=builder /app/public ./public # Set the correct permission for prerender cache RUN mkdir .next RUN chown nextjs:nodejs .next # Automatically leverage output traces to reduce image size COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./ COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static USER nextjs EXPOSE 3000 ENV PORT=3000 ENV HOSTNAME="0.0.0.0" CMD ["node", "server.js"] ``` Create a `.dockerignore` file to exclude unnecessary files: ``` # .dockerignore Dockerfile .dockerignore node_modules npm-debug.log .next .git .gitignore README.md .env*.local ``` Build and run the Docker container: ``` # Build the image docker build -t nextjs-app . # Run the container docker run -d \\ --name nextjs-app \\ --restart unless-stopped \\ -p 3000:3000 \\ -e DATABASE_URL="your-database-url" \\ nextjs-app ``` For more complex setups with Docker Compose, including databases and other services: ``` # docker-compose.yml version: '3.8' services: nextjs: build: context: . dockerfile: Dockerfile container_name: nextjs-app restart: unless-stopped ports: - "3000:3000" environment: - NODE_ENV=production - DATABASE_URL=postgresql://user:password@db:5432/mydb depends_on: - db networks: - app-network db: image: postgres:16-alpine container_name: postgres-db restart: unless-stopped environment: - POSTGRES_USER=user - POSTGRES_PASSWORD=password - POSTGRES_DB=mydb volumes: - postgres-data:/var/lib/postgresql/data networks: - app-network volumes: postgres-data: networks: app-network: driver: bridge ``` Use our [Dockerfile generator](https://docker.servercompass.app/) to create custom Dockerfiles for your specific needs. ## Step 7: Configure Nginx Reverse Proxy Nginx acts as a reverse proxy, handling SSL termination, compression, and static file serving. This offloads work from Node.js and improves performance. Install Nginx: ``` sudo apt install -y nginx ``` Create a configuration file for your Next.js app: ``` # /etc/nginx/sites-available/nextjs-app upstream nextjs_upstream { server 127.0.0.1:3000; keepalive 64; } server { listen 80; server_name yourdomain.com www.yourdomain.com; # Security headers add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; # Gzip compression gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_types text/plain text/css text/xml application/json application/javascript application/rss+xml application/atom+xml image/svg+xml; # Proxy settings location / { proxy_pass http://nextjs_upstream; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; proxy_read_timeout 60s; proxy_send_timeout 60s; } # Cache static assets location /_next/static { proxy_pass http://nextjs_upstream; proxy_cache_valid 60m; add_header Cache-Control "public, max-age=31536000, immutable"; } # Cache public folder assets location /public { proxy_pass http://nextjs_upstream; proxy_cache_valid 60m; add_header Cache-Control "public, max-age=31536000, immutable"; } } ``` Enable the site and restart Nginx: ``` # Create symbolic link sudo ln -s /etc/nginx/sites-available/nextjs-app /etc/nginx/sites-enabled/ # Remove default site (optional) sudo rm /etc/nginx/sites-enabled/default # Test configuration sudo nginx -t # Restart Nginx sudo systemctl restart nginx ``` Use our [Nginx config generator](/tools/nginx-config-generator) for custom configurations, and our [robots.txt generator](/tools/robots-txt-generator) to control how search engines and AI crawlers access your Next.js app. ## Step 8: SSL Certificate Setup Let's Encrypt provides free SSL certificates. We'll use Certbot to automate the process: ``` # Install Certbot sudo apt install -y certbot python3-certbot-nginx # Obtain and install certificate sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com # Follow the prompts to complete setup ``` Certbot will: - Obtain a certificate from Let's Encrypt - Modify your Nginx configuration to use HTTPS - Set up automatic HTTP to HTTPS redirection - Configure a cron job for automatic renewal Verify automatic renewal is set up: ``` sudo certbot renew --dry-run ``` Your Nginx configuration will be updated to include SSL settings. The final configuration will look something like this: ``` server { listen 443 ssl http2; server_name yourdomain.com www.yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; ssl_session_timeout 1d; ssl_session_cache shared:SSL:50m; ssl_session_tickets off; # Modern SSL configuration ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; # HSTS add_header Strict-Transport-Security "max-age=63072000" always; # ... rest of configuration } ``` ## Step 9: Environment Variables Management Managing environment variables securely is critical for production deployments. There are several approaches: ### Option 1: .env Files Create a `.env.production` file on your server (not in Git): ``` # ~/apps/your-nextjs-app/.env.production DATABASE_URL=postgresql://user:password@localhost:5432/mydb NEXTAUTH_SECRET=your-secret-key NEXTAUTH_URL=https://yourdomain.com STRIPE_SECRET_KEY=sk_live_... NEXT_PUBLIC_API_URL=https://api.yourdomain.com ``` For PM2, reference the env file in your ecosystem config or load it manually: ``` # Load env vars before starting export $(cat .env.production | xargs) && pm2 start ecosystem.config.js ``` ### Option 2: PM2 Environment Variables Add environment variables directly to your ecosystem.config.js: ``` module.exports = { apps: [{ name: 'nextjs-app', script: '.next/standalone/server.js', env_production: { NODE_ENV: 'production', DATABASE_URL: 'postgresql://user:password@localhost:5432/mydb', NEXTAUTH_SECRET: 'your-secret-key', }, }], } ``` ### Option 3: Docker Environment Variables Use an env file with Docker: ``` docker run -d --env-file .env.production -p 3000:3000 nextjs-app ``` Or with Docker Compose: ``` services: nextjs: env_file: - .env.production ``` Use our [env file builder](/tools/env-file-builder) to generate properly formatted environment files. ## The Easy Way: Deploy with Server Compass Everything we've covered so far — PM2 configuration, Docker builds, Nginx setup, SSL certificates, environment variables — is handled automatically by [Server Compass](/). Server Compass is a desktop application that turns complex VPS deployment into a visual workflow: - **One-click Next.js deployment** — Server Compass detects Next.js projects automatically, generates optimized Dockerfiles, and deploys with zero configuration. - **GitHub integration** — Connect your repository and deploy on every push with GitHub Actions-powered CI/CD. - **Automatic SSL** — SSL certificates are provisioned and renewed automatically using Let's Encrypt. - **Environment variable vault** — Store secrets securely with AES-256-GCM encryption, synced to your server at deploy time. - **Zero-downtime deployments** — Blue-green deployment strategy ensures your app never goes offline during updates. - **Real-time monitoring** — View container logs, CPU/memory usage, and deployment history from a single dashboard. Instead of writing configuration files and running terminal commands, you get a visual interface that handles everything. It's the Vercel experience on your own infrastructure. [Download Server Compass](/) — $29 one-time, no subscription, no usage fees. ## Vercel vs VPS Cost Comparison Here's a realistic cost comparison for a Next.js application with moderate traffic (100,000 page views/month): Metric Vercel Pro Vercel Team Self-Hosted VPS Base cost $20/month $20/user/month $5–$10/month Bandwidth (100GB) Included Included Unlimited\* Serverless functions 1M included, then $0.6/M 10M included Unlimited Image optimization 1,000 included, then $5/1,000 5,000 included Unlimited (self-hosted) Build minutes 6,000/month 24,000/month Unlimited Concurrent builds 1 3 Limited by CPU Analytics $10/month add-on $10/month add-on Free (self-hosted) **Typical monthly cost** **$30–$100+** **$60–$200+** **$5–$20** **Annual cost** **$360–$1,200+** **$720–$2,400+** **$60–$240** \*Most VPS providers include 1–20TB of bandwidth, which is effectively unlimited for most applications. The cost difference becomes even more significant at scale. At 1 million page views per month, Vercel costs can exceed $500/month, while a $20 VPS handles the traffic easily. Add Server Compass at $29 one-time, and the entire first year of self-hosting costs less than two months of Vercel Pro. ## Deployment Checklist Before going live, verify these items: - `output: 'standalone'` is set in next.config.js - Static files are copied to standalone folder - PM2 or Docker is configured and running - Nginx reverse proxy is configured - SSL certificate is installed and auto-renewing - Environment variables are set (not in Git) - Firewall allows only ports 80, 443, and SSH - PM2 is configured to start on boot - Logs are being written and rotated - Health check endpoint is working ## Updating Your Application To deploy updates, follow this process: ``` cd ~/apps/your-nextjs-app # Pull latest changes git pull origin main # Install dependencies (if changed) npm ci # Build the application npm run build # Copy static files cp -r .next/static .next/standalone/.next/ cp -r public .next/standalone/ # Restart PM2 pm2 restart nextjs-app ``` For Docker deployments: ``` cd ~/apps/your-nextjs-app # Pull latest changes git pull origin main # Rebuild and restart docker compose down docker compose build --no-cache docker compose up -d ``` Consider setting up GitHub Actions for automated deployments. Our guide on [GitHub Actions for zero-downtime deployments](/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments) covers this in detail. ## Troubleshooting Common Issues ### Application Not Starting Check PM2 logs for errors: ``` pm2 logs nextjs-app --lines 100 ``` Common causes: - Missing environment variables - Port already in use (check with `lsof -i :3000`) - Incorrect path in ecosystem.config.js - Missing static files in standalone folder ### 502 Bad Gateway This usually means Nginx can't connect to your Node.js application: - Verify the app is running: `pm2 status` - Check the upstream port matches in Nginx config - Look at Nginx error logs: `sudo tail -f /var/log/nginx/error.log` ### SSL Certificate Issues If certificate renewal fails: ``` # Check certificate status sudo certbot certificates # Force renewal sudo certbot renew --force-renewal # Check for port conflicts sudo lsof -i :80 ``` ### Memory Issues Next.js can consume significant memory during builds. If your server runs out of memory: - Add swap space (at least 2GB for small VPS) - Build locally and deploy the built files - Use Docker with build stages to limit memory during build ## Frequently Asked Questions ### Can I use Next.js static export instead? Yes, if your app doesn't use server-side features. Set `output: 'export'` in next.config.js, and deploy the generated `out` folder to any static hosting or serve it directly with Nginx. However, you lose API routes, server components, and dynamic rendering. ### Which VPS provider should I use? All major providers work well. Hetzner offers the best value in Europe, DigitalOcean and Linode are popular in the US, and Vultr has good global coverage. For a Next.js app, start with 1GB RAM / 1 vCPU ($5–$6/month) and scale up as needed. ### Does ISR (Incremental Static Regeneration) work on a VPS? Yes, ISR works in standalone mode. The revalidation cache is stored in `.next/cache`. For multi-instance deployments, you'll need a shared cache (Redis) or accept that different instances may have different cached versions. ### What about Next.js Image Optimization? The built-in image optimization works in standalone mode. Images are optimized on-demand and cached in `.next/cache/images`. For better performance, consider using a CDN like Cloudflare in front of your server. ### Can I run multiple Next.js apps on one VPS? Absolutely. Run each app on a different port (3000, 3001, 3002, etc.) and configure Nginx to route traffic based on domain name or path. Server Compass makes this easy with its multi-app support. ### Do I need a separate database server? For small to medium applications, running PostgreSQL or MySQL on the same VPS is fine. For larger applications or when you need high availability, consider a managed database service or a dedicated database server. ## Next Steps You now have a production Next.js deployment on your own VPS. Here are some ways to improve it further: - [Set up GitHub Actions for automated deployments](/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments) - Add a CDN like Cloudflare for global caching and DDoS protection - Configure monitoring with tools like Prometheus + Grafana or use Server Compass's built-in monitoring - Set up automated backups for your database and configuration - [Self-host PostgreSQL for your database needs](/blog/how-to-self-host-postgresql-on-your-vps) Ready to simplify your VPS deployments? [Try Server Compass](/) — deploy Next.js, Node.js, Docker apps, and 100+ templates with a visual interface. $29 one-time, no subscription. --- **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. --- ## Deploy Python FastAPI on VPS with Docker (2026 Guide) Source: https://servercompass.app/blog/deploy-python-fastapi-on-vps-with-docker Published: 2026-03-06 Tags: fastapi, python, docker, vps-deploy, tutorials, self-hosted Complete guide to deploy FastAPI on your VPS with Docker. Learn how to create optimized Dockerfiles, configure docker-compose, set up Nginx/Traefik reverse proxy, SSL certificates, and production-ready Uvicorn settings for high-performance Python APIs. FastAPI has become the go-to framework for building high-performance Python APIs. Its async support, automatic OpenAPI documentation, and type hints make it a joy to work with. But when it comes to deploying FastAPI on a VPS, many developers hit a wall. This guide walks you through deploying a production-ready FastAPI application on your VPS using Docker. By the end, you'll have a containerized API running behind a reverse proxy with SSL certificates, environment variable management, and optimized Uvicorn settings. **What you'll learn:** - Creating an optimized Dockerfile for FastAPI - Setting up Docker Compose for multi-container deployments - Configuring Nginx or Traefik as a reverse proxy - Automating SSL certificates with Let's Encrypt - Managing environment variables securely - Tuning Uvicorn for production workloads ## Why Deploy FastAPI on a VPS? Before diving into the deployment steps, let's address why you might choose a VPS over managed platforms like AWS Lambda, Google Cloud Run, or Heroku. - **Cost efficiency** — A $5-10/month VPS can handle thousands of requests per second. Serverless platforms charge per invocation, which adds up quickly for APIs with consistent traffic. - **Full control** — You own the server. Install any Python package, configure system-level settings, and optimize for your specific workload. - **Persistent connections** — FastAPI excels at WebSockets and Server-Sent Events. VPS deployments maintain long-lived connections without the cold start penalties of serverless. - **No vendor lock-in** — Your Docker image runs anywhere. Move between providers without rewriting deployment configs. - **Data sovereignty** — Keep your data on servers in your chosen region, under your control. ## Prerequisites Before you begin, make sure you have: - **A VPS** — Any provider works: DigitalOcean, Hetzner, Linode, Vultr, or AWS EC2. Minimum 1GB RAM recommended for comfortable builds. - **SSH access** — Root or sudo privileges on your server. - **A domain name** — Point an A record to your VPS IP address (required for SSL). - **Docker installed locally** — For building and testing images before deployment. - **A FastAPI project** — If you don't have one, we'll create a sample in the next section. ## Step 1: Create Your FastAPI Application If you already have a FastAPI project, skip to Step 2. Otherwise, let's create a simple API to demonstrate the deployment process. Create a new directory and set up the project structure: ``` my-fastapi-app/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── routers/ │ │ ├── __init__.py │ │ └── items.py │ └── models/ │ ├── __init__.py │ └── item.py ├── requirements.txt ├── Dockerfile └── docker-compose.yml ``` Create `app/main.py` with your FastAPI application: ``` from fastapi import FastAPI from fastapi.middleware.cors import CORSMiddleware from app.routers import items import os app = FastAPI( title="My FastAPI App", description="A production-ready FastAPI application", version="1.0.0", docs_url="/docs", redoc_url="/redoc", ) # CORS configuration origins = os.getenv("CORS_ORIGINS", "http://localhost:3000").split(",") app.add_middleware( CORSMiddleware, allow_origins=origins, allow_credentials=True, allow_methods=["*"], allow_headers=["*"], ) # Include routers app.include_router(items.router, prefix="/api/v1", tags=["items"]) @app.get("/health") async def health_check(): """Health check endpoint for load balancers and monitoring.""" return {"status": "healthy", "version": "1.0.0"} @app.get("/") async def root(): return {"message": "Welcome to My FastAPI App"} ``` Create `app/routers/items.py` for your API routes: ``` from fastapi import APIRouter, HTTPException from pydantic import BaseModel from typing import Optional from uuid import uuid4 router = APIRouter() # In-memory storage (replace with database in production) items_db: dict = {} class ItemCreate(BaseModel): name: str description: Optional[str] = None price: float class Item(ItemCreate): id: str @router.get("/items") async def list_items(): """List all items.""" return list(items_db.values()) @router.post("/items", response_model=Item) async def create_item(item: ItemCreate): """Create a new item.""" item_id = str(uuid4()) db_item = Item(id=item_id, **item.model_dump()) items_db[item_id] = db_item return db_item @router.get("/items/", response_model=Item) async def get_item(item_id: str): """Get a specific item by ID.""" if item_id not in items_db: raise HTTPException(status_code=404, detail="Item not found") return items_db[item_id] @router.delete("/items/") async def delete_item(item_id: str): """Delete an item.""" if item_id not in items_db: raise HTTPException(status_code=404, detail="Item not found") del items_db[item_id] return {"message": "Item deleted"} ``` Create `requirements.txt` with your dependencies: ``` fastapi==0.109.0 uvicorn[standard]==0.27.0 pydantic==2.5.3 python-multipart==0.0.6 httpx==0.26.0 ``` ## Step 2: Create an Optimized Dockerfile for FastAPI A well-crafted Dockerfile is crucial for production deployments. We'll use a multi-stage build to minimize the final image size and a non-root user for security. Create your `Dockerfile`: ``` # Stage 1: Build dependencies FROM python:3.12-slim as builder WORKDIR /app # Install build dependencies RUN apt-get update && apt-get install -y --no-install-recommends \\ build-essential \\ && rm -rf /var/lib/apt/lists/* # Create virtual environment RUN python -m venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" # Install Python dependencies COPY requirements.txt . RUN pip install --no-cache-dir --upgrade pip && \\ pip install --no-cache-dir -r requirements.txt # Stage 2: Production image FROM python:3.12-slim as production WORKDIR /app # Create non-root user for security RUN groupadd -r appgroup && useradd -r -g appgroup appuser # Copy virtual environment from builder COPY --from=builder /opt/venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" # Copy application code COPY --chown=appuser:appgroup ./app ./app # Switch to non-root user USER appuser # Expose the application port EXPOSE 8000 # Health check HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \\ CMD python -c "import httpx; httpx.get('http://localhost:8000/health')" || exit 1 # Run with Uvicorn CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"] ``` **Key optimizations in this Dockerfile:** - **Multi-stage build** — Build dependencies are discarded, reducing image size by 50-70%. - **Virtual environment** — Keeps dependencies isolated and makes the final COPY cleaner. - **Non-root user** — Runs the app as `appuser` instead of root for security. - **Health check** — Enables automatic container restart if the app becomes unresponsive. - **Slim base image** — Uses `python:3.12-slim` instead of the full image (100MB vs 1GB+). Need help generating Dockerfiles? The [Dockerfile Generator](https://docker.servercompass.app/) creates optimized Dockerfiles for Python, Node.js, Go, and more with best practices built in. ## Step 3: Docker Compose Setup Docker Compose orchestrates your containers and makes deployment reproducible. Create `docker-compose.yml`: ``` version: "3.9" services: fastapi: build: context: . dockerfile: Dockerfile container_name: fastapi-app restart: unless-stopped ports: - "8000:8000" environment: - CORS_ORIGINS=https://yourdomain.com - LOG_LEVEL=info env_file: - .env healthcheck: test: ["CMD", "python", "-c", "import httpx; httpx.get('http://localhost:8000/health')"] interval: 30s timeout: 10s retries: 3 start_period: 10s networks: - app-network # Optional: Add PostgreSQL database postgres: image: postgres:16-alpine container_name: fastapi-postgres restart: unless-stopped environment: POSTGRES_USER: \${POSTGRES_USER:-fastapi} POSTGRES_PASSWORD: \${POSTGRES_PASSWORD:?error} POSTGRES_DB: \${POSTGRES_DB:-fastapi_db} volumes: - postgres_data:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U \${POSTGRES_USER:-fastapi}"] interval: 10s timeout: 5s retries: 5 networks: - app-network # Optional: Add Redis for caching redis: image: redis:7-alpine container_name: fastapi-redis restart: unless-stopped command: redis-server --appendonly yes volumes: - redis_data:/data healthcheck: test: ["CMD", "redis-cli", "ping"] interval: 10s timeout: 5s retries: 5 networks: - app-network networks: app-network: driver: bridge volumes: postgres_data: redis_data: ``` This compose file includes optional PostgreSQL and Redis services. Remove them if you don't need a database or cache. Create a `.env` file for your environment variables (never commit this to Git): ``` # Database POSTGRES_USER=fastapi POSTGRES_PASSWORD=your-secure-password-here POSTGRES_DB=fastapi_db DATABASE_URL=postgresql://fastapi:your-secure-password-here@postgres:5432/fastapi_db # Redis REDIS_URL=redis://redis:6379/0 # Application SECRET_KEY=your-secret-key-generate-with-openssl-rand-hex-32 CORS_ORIGINS=https://yourdomain.com,https://www.yourdomain.com LOG_LEVEL=info DEBUG=false ``` Looking for more Docker Compose examples? Check out our [Python templates](/templates/python) for pre-configured stacks including FastAPI with PostgreSQL, Django, and Flask deployments. ## Step 4: Connect to Your VPS and Deploy Now let's deploy to your VPS. First, SSH into your server: ``` ssh root@your-server-ip ``` Install Docker and Docker Compose if they're not already installed: ``` # Install Docker curl -fsSL https://get.docker.com | sh # Add your user to the docker group (optional, for non-root) usermod -aG docker $USER # Verify installation docker --version docker compose version ``` Create a directory for your application and transfer your files: ``` # On your VPS mkdir -p /var/www/fastapi-app cd /var/www/fastapi-app # From your local machine (run this locally, not on VPS) scp -r ./app ./requirements.txt ./Dockerfile ./docker-compose.yml ./.env root@your-server-ip:/var/www/fastapi-app/ ``` Alternatively, if your code is on GitHub, clone the repository: ``` # On your VPS cd /var/www/fastapi-app git clone https://github.com/yourusername/your-repo.git . # Create .env file (don't store secrets in git) nano .env ``` Build and start your containers: ``` cd /var/www/fastapi-app # Build the image docker compose build # Start in detached mode docker compose up -d # Check if containers are running docker compose ps # View logs docker compose logs -f fastapi ``` Test that your API is running: ``` curl http://localhost:8000/health # {"status":"healthy","version":"1.0.0"} curl http://localhost:8000/docs # Should return the OpenAPI documentation HTML ``` ## Step 5: Configure Nginx or Traefik Reverse Proxy Running FastAPI directly on port 80/443 is not recommended. A reverse proxy handles SSL termination, load balancing, and security headers. Choose either Nginx or Traefik. ### Option A: Nginx Reverse Proxy Add Nginx to your `docker-compose.yml`: ``` nginx: image: nginx:alpine container_name: nginx-proxy restart: unless-stopped ports: - "80:80" - "443:443" volumes: - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro - ./nginx/conf.d:/etc/nginx/conf.d:ro - ./certbot/conf:/etc/letsencrypt:ro - ./certbot/www:/var/www/certbot:ro depends_on: - fastapi networks: - app-network ``` Create `nginx/conf.d/default.conf`: ``` upstream fastapi_backend { server fastapi:8000; keepalive 32; } server { listen 80; server_name yourdomain.com www.yourdomain.com; location /.well-known/acme-challenge/ { root /var/www/certbot; } location / { return 301 https://$host$request_uri; } } server { listen 443 ssl http2; server_name yourdomain.com www.yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; # SSL settings ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 1d; # Security headers add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; # Gzip compression gzip on; gzip_vary on; gzip_types application/json text/plain application/javascript; location / { proxy_pass http://fastapi_backend; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header Connection ""; # WebSocket support proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # Timeouts proxy_connect_timeout 60s; proxy_send_timeout 60s; proxy_read_timeout 60s; } } ``` ### Option B: Traefik Reverse Proxy Traefik is a modern reverse proxy with automatic SSL and Docker integration. Update your `docker-compose.yml`: ``` {`version: "3.9" services: traefik: image: traefik:v3.0 container_name: traefik restart: unless-stopped command: - "--api.dashboard=true" - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=your@email.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - "/var/run/docker.sock:/var/run/docker.sock:ro" - "./letsencrypt:/letsencrypt" networks: - app-network fastapi: build: context: . dockerfile: Dockerfile container_name: fastapi-app restart: unless-stopped labels: - "traefik.enable=true" - "traefik.http.routers.fastapi.rule=Host(\`yourdomain.com\`)" - "traefik.http.routers.fastapi.entrypoints=websecure" - "traefik.http.routers.fastapi.tls.certresolver=letsencrypt" - "traefik.http.services.fastapi.loadbalancer.server.port=8000" # HTTP to HTTPS redirect - "traefik.http.routers.fastapi-http.rule=Host(\`yourdomain.com\`)" - "traefik.http.routers.fastapi-http.entrypoints=web" - "traefik.http.routers.fastapi-http.middlewares=https-redirect" - "traefik.http.middlewares.https-redirect.redirectscheme.scheme=https" environment: - CORS_ORIGINS=https://yourdomain.com env_file: - .env networks: - app-network networks: app-network: driver: bridge`} ``` Traefik automatically obtains and renews SSL certificates from Let's Encrypt. No manual certbot setup required. ## Step 6: SSL Certificate Setup If you chose Traefik, SSL is automatic. For Nginx, use Certbot: ``` # Add certbot to docker-compose.yml certbot: image: certbot/certbot container_name: certbot volumes: - ./certbot/conf:/etc/letsencrypt - ./certbot/www:/var/www/certbot entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $!; done;'" # Initial certificate generation (run once) docker compose run --rm certbot certonly --webroot -w /var/www/certbot \\ --email your@email.com \\ -d yourdomain.com -d www.yourdomain.com \\ --agree-tos --no-eff-email ``` Certbot runs every 12 hours to check for renewals. Certificates are automatically renewed 30 days before expiration. ## Step 7: Environment Variables Management Secure environment variable handling is critical. Here are best practices for FastAPI deployments: ### Use Pydantic Settings Create `app/config.py` for type-safe configuration: ``` from pydantic_settings import BaseSettings from functools import lru_cache class Settings(BaseSettings): # Application app_name: str = "My FastAPI App" debug: bool = False log_level: str = "info" # Security secret_key: str cors_origins: list[str] = ["http://localhost:3000"] # Database database_url: str | None = None postgres_user: str = "fastapi" postgres_password: str = "" postgres_db: str = "fastapi_db" # Redis redis_url: str = "redis://localhost:6379/0" class Config: env_file = ".env" env_file_encoding = "utf-8" @lru_cache def get_settings() -> Settings: return Settings() settings = get_settings() ``` ### Validate on Startup Add validation in `app/main.py` to fail fast if required variables are missing: ``` from app.config import settings @app.on_event("startup") async def validate_settings(): """Validate required settings on startup.""" if not settings.secret_key or settings.secret_key == "changeme": raise ValueError("SECRET_KEY must be set to a secure value") if settings.debug and settings.log_level == "info": print("Warning: Running in debug mode with info logging") ``` ### Secrets on VPS Never commit `.env` files to Git. On your VPS, create them manually or use a secrets manager: ``` # Generate a secure secret key openssl rand -hex 32 # Create .env file with restricted permissions touch .env chmod 600 .env nano .env ``` ## Step 8: Uvicorn Production Settings The default Uvicorn settings are for development. For production, optimize worker count, timeouts, and logging. Update the CMD in your `Dockerfile`: ``` # Production Uvicorn configuration CMD ["uvicorn", "app.main:app", \\ "--host", "0.0.0.0", \\ "--port", "8000", \\ "--workers", "4", \\ "--loop", "uvloop", \\ "--http", "httptools", \\ "--timeout-keep-alive", "120", \\ "--access-log", \\ "--log-level", "info"] ``` **Key production settings:** - **\--workers** — Number of worker processes. Rule of thumb: 2-4x CPU cores. For a 2-core VPS, use 4 workers. - **\--loop uvloop** — High-performance async event loop (2-4x faster than default). - **\--http httptools** — Fast HTTP parser written in C. - **\--timeout-keep-alive** — Keep connections alive for 120 seconds to reduce TCP overhead. - **\--access-log** — Enable access logging for monitoring and debugging. For more control, create a `gunicorn.conf.py` and use Gunicorn with Uvicorn workers: ``` # gunicorn.conf.py import multiprocessing # Worker configuration workers = multiprocessing.cpu_count() * 2 + 1 worker_class = "uvicorn.workers.UvicornWorker" worker_connections = 1000 timeout = 120 keepalive = 5 # Server socket bind = "0.0.0.0:8000" backlog = 2048 # Logging accesslog = "-" errorlog = "-" loglevel = "info" access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s" %(D)s' # Process naming proc_name = "fastapi-app" # Server mechanics daemon = False pidfile = None umask = 0 user = None group = None tmp_upload_dir = None ``` Update your Dockerfile to use Gunicorn: ``` # Add gunicorn to requirements.txt # gunicorn==21.2.0 CMD ["gunicorn", "app.main:app", "-c", "gunicorn.conf.py"] ``` ## The Easy Way: Deploy FastAPI with Server Compass All of the above steps — Dockerfiles, docker-compose, reverse proxy, SSL, environment variables — can take hours to set up correctly. And that's if everything works on the first try. [Server Compass](/) eliminates this complexity. It's a desktop app that deploys Docker apps to your VPS with a visual interface. No SSH commands, no YAML editing, no manual certificate setup. ![Server Compass framework detection showing FastAPI project with automatic Dockerfile generation](/app-screenshots/feature-framework-detect.jpg) ### How It Works 1. **Connect your VPS** — Add your server with SSH credentials. Server Compass automatically installs Docker if needed. 2. **Select your project** — Point to your GitHub repository or local folder. Server Compass detects FastAPI and generates an optimized Dockerfile automatically. 3. **Configure deployment** — Set environment variables, port mappings, and domain. The visual interface validates your config before deployment. 4. **Deploy** — One click builds your image, pushes it to your VPS, and starts the container. Watch real-time logs as it happens. 5. **SSL included** — Traefik is automatically configured with Let's Encrypt. Your FastAPI app is live with HTTPS in minutes. Need the Dockerfile for reference? Use our [Dockerfile Generator](https://docker.servercompass.app/) to create optimized configurations for FastAPI, Django, Flask, and other Python frameworks. Looking for pre-built templates? Browse our [Python templates](/templates/python) including FastAPI with PostgreSQL, Redis, and Celery worker configurations. ### Why Server Compass? - **Framework detection** — Automatically identifies FastAPI, Django, Flask, and generates appropriate Dockerfiles. - **Build anywhere** — Build on your VPS, locally, or with GitHub Actions for low-memory servers. - **Zero-downtime deploys** — Blue-green deployments ensure your API never goes offline during updates. - **Environment vault** — Store secrets encrypted locally. They're injected at deploy time without ever hitting disk on your VPS. - **One-time payment** — $29 forever. No subscriptions, no per-server fees, no deploy limits. ## Frequently Asked Questions ### What VPS size do I need for FastAPI? A 1GB RAM VPS handles most FastAPI applications comfortably. For builds, 2GB is recommended to avoid memory issues during `pip install`. Alternatively, build locally or with GitHub Actions and push the pre-built image to your VPS. ### How many Uvicorn workers should I use? The general formula is `(2 x CPU cores) + 1`. For a 2-core VPS, use 5 workers. For async-heavy workloads with lots of I/O (database queries, external APIs), you can increase this. Monitor memory usage — each worker consumes 50-200MB depending on your app. ### Should I use Gunicorn or Uvicorn directly? For most deployments, Uvicorn alone is fine. Use Gunicorn with Uvicorn workers if you need: - Graceful restarts (Gunicorn handles worker lifecycle) - More control over worker management - Integration with monitoring tools that expect Gunicorn ### How do I connect FastAPI to PostgreSQL in Docker? Use the Docker service name as the hostname. If your PostgreSQL service is named `postgres` in docker-compose, the connection string is: ``` DATABASE_URL=postgresql://user:password@postgres:5432/dbname ``` Docker's internal DNS resolves `postgres` to the container's IP. ### Does this setup support WebSockets? Yes. Both Nginx and Traefik configurations in this guide include WebSocket support. Ensure your `--timeout-keep-alive` is set high enough for long-lived connections. ### How do I scale FastAPI horizontally? For horizontal scaling, run multiple FastAPI containers behind a load balancer: ``` # docker-compose.yml services: fastapi: deploy: replicas: 3 # ... rest of config ``` Use Traefik or Nginx as a load balancer to distribute requests. For stateful features (sessions, rate limiting), use Redis to share state between containers. ### How do I monitor FastAPI in production? Add Prometheus metrics with `prometheus-fastapi-instrumentator`: ``` from prometheus_fastapi_instrumentator import Instrumentator Instrumentator().instrument(app).expose(app) ``` Pair with Grafana for dashboards. For logging, configure structured JSON logs and ship to Loki, Elasticsearch, or your preferred log aggregator. ### Are there cold starts like serverless? No. Your FastAPI container runs continuously on the VPS. There are no cold starts. Requests are handled immediately by the already-running Uvicorn workers. ## Conclusion Deploying FastAPI on a VPS gives you performance, control, and cost savings that managed platforms can't match. With Docker, you get reproducible deployments. With a proper reverse proxy and SSL, you get production-grade security. The manual setup takes time to get right, but the payoff is a deployment pipeline you fully understand and control. For those who want the same result without the manual work, [Server Compass](/) provides a visual interface that handles Dockerfiles, compose files, SSL, and deployments automatically. Ready to deploy your FastAPI app? Start with a [Python template](/templates/python) or generate a [custom Dockerfile](https://docker.servercompass.app/) for your project. --- **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. 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. --- ## Deploy React App to VPS with Nginx (Complete Guide) Source: https://servercompass.app/blog/deploy-react-app-to-vps-with-nginx Published: 2026-03-06 Tags: react, nginx, vps-deploy, tutorials, self-hosted, docker Learn how to deploy your React application to a VPS with Nginx step by step. This comprehensive guide covers production builds, Nginx configuration for SPAs, SSL with Let's Encrypt, gzip compression, caching headers, and a Docker alternative. Deploying a React application to a VPS with Nginx gives you complete control over your hosting environment, predictable costs, and the flexibility to customize every aspect of your server configuration. Unlike managed platforms that charge based on bandwidth or build minutes, a $5/month VPS can host multiple React apps with unlimited traffic. This guide walks you through every step of deploying a React app to a VPS with Nginx — from building your production bundle to configuring SSL, gzip compression, and optimal caching headers. We'll also cover a Docker alternative and compare costs against platforms like Netlify. ## Why Host React on Your Own VPS Before diving into the technical steps, let's understand why developers choose to self-host React applications on a VPS instead of using platforms like Netlify, Vercel, or Cloudflare Pages: - **Predictable costs** — A $5-10/month VPS can host unlimited React apps with no bandwidth overage fees. On Netlify, exceeding 100GB bandwidth costs $55 per additional 100GB. - **Full server control** — Configure Nginx exactly how you want. Add custom headers, implement rate limiting, set up complex routing rules, or run backend services alongside your frontend. - **No build minute limits** — Deploy as often as you want without worrying about monthly build quotas. - **Co-locate with your API** — Run your React frontend and backend API on the same server with zero network latency between them. - **Learning experience** — Understanding how web servers work makes you a better developer and helps with debugging production issues. - **Data sovereignty** — Your files stay on servers you control, which matters for compliance or privacy requirements. ## Prerequisites Before we begin, make sure you have: - **A React application** ready to deploy (Create React App, Vite, or any React setup) - **A VPS** from any provider (DigitalOcean, Hetzner, Vultr, Linode, etc.) running Ubuntu 22.04 or later - **A domain name** pointing to your VPS IP address (for SSL configuration) - **SSH access** to your server with a user that has sudo privileges - **Basic terminal knowledge** — comfort with running commands via SSH If you don't have a VPS yet, providers like Hetzner offer servers starting at $4/month, or DigitalOcean and Vultr at $5/month. A basic server with 1GB RAM and 1 vCPU is sufficient for serving static React builds. ## Step 1: Build React App for Production First, create an optimized production build of your React application. This step happens on your local machine (or in a CI pipeline). ### For Create React App `# Navigate to your project directory cd my-react-app # Install dependencies (if not already installed) npm install # Create production build npm run build` This creates a `build/` directory containing your optimized, minified React application with hashed filenames for cache busting. ### For Vite `# Navigate to your project directory cd my-vite-app # Install dependencies npm install # Create production build npm run build` Vite outputs to a `dist/` directory by default. The build includes tree-shaking, code splitting, and optimized asset handling. ### Verify Your Build Before uploading, test your build locally to catch any issues: `# For Create React App npx serve -s build # For Vite npx serve dist` Visit `http://localhost:3000` (or the port shown) and verify your app works correctly. Test navigation, ensure assets load, and check for console errors. ## Step 2: Connect to VPS Connect to your server via SSH: `ssh username@your-server-ip` Replace `username` with your actual username (often `root` for initial setup, though you should create a non-root user for security) and `your-server-ip` with your VPS IP address. Once connected, update your system packages: `sudo apt update && sudo apt upgrade -y` ## Step 3: Install Nginx Install Nginx, the high-performance web server that will serve your React app: `sudo apt install nginx -y` Start Nginx and enable it to run on system boot: `sudo systemctl start nginx sudo systemctl enable nginx` Verify Nginx is running: `sudo systemctl status nginx` You should see "active (running)" in the output. You can also visit your server's IP address in a browser — you should see the default Nginx welcome page. ### Configure Firewall If you're using UFW (Ubuntu's default firewall), allow HTTP and HTTPS traffic: `sudo ufw allow 'Nginx Full' sudo ufw enable sudo ufw status` ## Step 4: Configure Nginx for React SPA React applications are Single Page Applications (SPAs), which means all routing is handled client-side by React Router (or your routing library of choice). This requires special Nginx configuration to ensure that all routes return `index.html`, allowing React to handle the routing. ### Create Nginx Configuration Create a new Nginx configuration file for your React app: `sudo nano /etc/nginx/sites-available/react-app` Add the following configuration (replace `yourdomain.com` with your actual domain): `server { listen 80; listen [::]:80; server_name yourdomain.com www.yourdomain.com; root /var/www/react-app; index index.html; # React Router support - serve index.html for all routes location / { try_files $uri $uri/ /index.html; } # Cache static assets aggressively location ~* \\.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control "public, immutable"; access_log off; } # Security headers add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; # Disable access to hidden files location ~ /\\. { deny all; access_log off; log_not_found off; } }` The key line is `try_files $uri $uri/ /index.html;` — this tells Nginx to first try serving the exact file requested, then try it as a directory, and finally fall back to `index.html`. This allows React Router to handle client-side routing for paths like `/dashboard`, `/users/123`, etc. ### Enable the Site Create a symbolic link to enable the site and remove the default configuration: `sudo ln -s /etc/nginx/sites-available/react-app /etc/nginx/sites-enabled/ sudo rm /etc/nginx/sites-enabled/default` Test the Nginx configuration for syntax errors: `sudo nginx -t` If the test passes, reload Nginx: `sudo systemctl reload nginx` Need help generating Nginx configurations? Try our free [Nginx Config Generator](/tools/nginx-config-generator) tool that creates optimized configs for React SPAs, reverse proxies, and more. ## Step 5: Upload Build Files Create the directory where your React app will live: `sudo mkdir -p /var/www/react-app sudo chown -R $USER:$USER /var/www/react-app` Now upload your build files from your local machine. Open a new terminal on your local machine (not the SSH session) and use `scp` or `rsync`: ### Using SCP `# For Create React App (build/ directory) scp -r ./build/* username@your-server-ip:/var/www/react-app/ # For Vite (dist/ directory) scp -r ./dist/* username@your-server-ip:/var/www/react-app/` ### Using Rsync (Recommended) Rsync is more efficient for subsequent deployments as it only transfers changed files: `# For Create React App rsync -avz --delete ./build/ username@your-server-ip:/var/www/react-app/ # For Vite rsync -avz --delete ./dist/ username@your-server-ip:/var/www/react-app/` The `--delete` flag removes files on the server that no longer exist in your local build, keeping the deployment clean. After uploading, verify your site loads by visiting your domain in a browser. At this point, it will be served over HTTP (not HTTPS). ## Step 6: SSL with Let's Encrypt Secure your site with a free SSL certificate from Let's Encrypt using Certbot. This is essential for security and SEO (Google ranks HTTPS sites higher). ### Install Certbot `sudo apt install certbot python3-certbot-nginx -y` ### Obtain SSL Certificate Run Certbot with the Nginx plugin. It will automatically configure SSL for your domain: `sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com` Certbot will prompt you for your email address (for renewal notifications) and ask if you want to redirect HTTP traffic to HTTPS. Choose **yes** for the redirect — this ensures all visitors use the secure version of your site. ### Verify Auto-Renewal Let's Encrypt certificates expire after 90 days, but Certbot sets up automatic renewal. Test the renewal process: `sudo certbot renew --dry-run` If successful, your certificates will automatically renew before expiration. ### Updated Nginx Configuration After running Certbot, your Nginx configuration will be automatically updated to include SSL settings. It will look something like this: `server { listen 80; listen [::]:80; server_name yourdomain.com www.yourdomain.com; return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name yourdomain.com www.yourdomain.com; ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem; include /etc/letsencrypt/options-ssl-nginx.conf; ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; root /var/www/react-app; index index.html; location / { try_files $uri $uri/ /index.html; } location ~* \\.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 1y; add_header Cache-Control "public, immutable"; access_log off; } add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; add_header X-XSS-Protection "1; mode=block" always; add_header Referrer-Policy "strict-origin-when-cross-origin" always; location ~ /\\. { deny all; } }` ## Step 7: Enable Gzip Compression Gzip compression reduces the size of files sent to browsers, significantly improving load times. Edit the main Nginx configuration: `sudo nano /etc/nginx/nginx.conf` Find the `http` block and add or update these gzip settings: `http { # ... existing settings ... # Gzip compression gzip on; gzip_vary on; gzip_proxied any; gzip_comp_level 6; gzip_min_length 1000; gzip_types text/plain text/css text/xml text/javascript application/json application/javascript application/x-javascript application/xml application/xml+rss application/vnd.ms-fontobject application/x-font-ttf font/opentype image/svg+xml image/x-icon; }` Test and reload Nginx: `sudo nginx -t sudo systemctl reload nginx` ### Verify Gzip is Working Test that gzip compression is active using curl: `curl -H "Accept-Encoding: gzip" -I https://yourdomain.com` Look for `Content-Encoding: gzip` in the response headers. You can also use browser DevTools — in the Network tab, check the "Content-Encoding" header for your JavaScript and CSS files. ## Step 8: Configure Caching Headers Proper caching dramatically improves repeat visitor performance. React build tools generate hashed filenames (like `main.abc123.js`), enabling aggressive caching — when the content changes, the hash changes, busting the cache automatically. We already added basic caching in Step 4, but here's a more comprehensive caching configuration: `server { # ... SSL and other settings ... root /var/www/react-app; index index.html; # HTML files - don't cache (they reference hashed assets) location ~* \\.html$ { expires -1; add_header Cache-Control "no-store, no-cache, must-revalidate"; } # JavaScript and CSS (hashed filenames) - cache for 1 year location ~* \\.(js|css)$ { expires 1y; add_header Cache-Control "public, immutable"; access_log off; } # Images, fonts, and other static assets location ~* \\.(png|jpg|jpeg|gif|ico|svg|webp|avif|woff|woff2|ttf|eot|otf)$ { expires 1y; add_header Cache-Control "public, immutable"; access_log off; } # JSON files (like manifest.json) - short cache location ~* \\.json$ { expires 1d; add_header Cache-Control "public"; } # React Router fallback location / { try_files $uri $uri/ /index.html; } }` Once your caching is configured, don't forget to set up a `robots.txt` file to control search engine crawling. Our [free robots.txt generator](/tools/robots-txt-generator) makes it easy to create one for your React SPA. Key caching strategies: - **HTML files**: Never cached, ensuring users always get the latest version that references current asset hashes - **JS/CSS with hashed names**: Cached for 1 year with `immutable` directive (browsers won't even check for updates) - **Images and fonts**: Cached for 1 year (update filenames if content changes) - **JSON files**: Short cache (1 day) for manifests and configuration files ## Docker Alternative: React with Nginx in a Container If you prefer containerized deployments, you can package your React app with Nginx in a Docker container. This approach offers several benefits: - Consistent environment between development and production - Easy rollbacks by switching container versions - Simplified deployment with Docker Compose or Kubernetes - Isolation from other applications on the server ### Create Dockerfile Create a `Dockerfile` in your React project root: `# Build stage FROM node:20-alpine AS build WORKDIR /app # Copy package files COPY package*.json ./ # Install dependencies RUN npm ci --only=production=false # Copy source code COPY . . # Build the app RUN npm run build # Production stage FROM nginx:alpine # Copy custom nginx config COPY nginx.conf /etc/nginx/conf.d/default.conf # Copy build output to nginx html directory COPY --from=build /app/build /usr/share/nginx/html # Expose port 80 EXPOSE 80 # Start nginx CMD ["nginx", "-g", "daemon off;"]` ### Create Nginx Config for Docker Create an `nginx.conf` file in your project root: `server { listen 80; server_name localhost; root /usr/share/nginx/html; index index.html; # Gzip compression gzip on; gzip_vary on; gzip_min_length 1000; gzip_types text/plain text/css text/xml text/javascript application/javascript application/json application/xml; # React Router support location / { try_files $uri $uri/ /index.html; } # Cache static assets location ~* \\.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ { expires 1y; add_header Cache-Control "public, immutable"; } # Security headers add_header X-Frame-Options "SAMEORIGIN" always; add_header X-Content-Type-Options "nosniff" always; }` ### Build and Run `# Build the Docker image docker build -t my-react-app . # Run the container docker run -d -p 80:80 --name react-app my-react-app` ### Docker Compose Example For a more complete setup with SSL using Traefik as a reverse proxy, create a `docker-compose.yml`: ``{`version: '3.8' services: react-app: build: . container_name: react-app restart: unless-stopped labels: - "traefik.enable=true" - "traefik.http.routers.react.rule=Host(\`yourdomain.com\`)" - "traefik.http.routers.react.entrypoints=websecure" - "traefik.http.routers.react.tls.certresolver=letsencrypt" networks: - web traefik: image: traefik:v2.10 container_name: traefik restart: unless-stopped command: - "--api.insecure=true" - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=your@email.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" ports: - "80:80" - "443:443" volumes: - "/var/run/docker.sock:/var/run/docker.sock:ro" - "./letsencrypt:/letsencrypt" networks: - web networks: web: external: true`}`` ![Server Compass framework detection showing React app configuration](/app-screenshots/feature-framework-detect.jpg) ## The Easy Way: Deploy React with Server Compass If configuring Nginx, SSL, and deployment scripts feels like too much work, [Server Compass](/) automates the entire process. It's a desktop app that deploys React applications to your VPS with a visual interface — no SSH commands or configuration files required. ### How It Works 1. **Connect your VPS** — Enter your server IP and credentials. Server Compass handles SSH setup automatically. 2. **Connect GitHub** — Link your repository with OAuth. Server Compass auto-detects React, Vite, Create React App, and 16+ other frameworks. 3. **Deploy** — Click deploy. Server Compass builds your app, configures Nginx with SPA routing, sets up SSL with Let's Encrypt, and handles caching headers automatically. ### Features for React Apps - **Framework auto-detection** — Automatically detects React, Vite, Next.js, and generates optimized Dockerfiles - **Automatic SSL** — Let's Encrypt certificates configured with one click - **SPA routing** — Nginx configured correctly for React Router out of the box - **Environment variables** — Securely manage `.env` files with AES-256-GCM encryption - **Zero-downtime deploys** — Blue-green deployment ensures no interruption for users - **GitHub Actions CI/CD** — Optionally generate GitHub Actions workflows for automated deployments Server Compass is a **one-time $19 purchase** with no monthly fees. Deploy unlimited apps to unlimited servers. ## Netlify vs VPS: Cost Comparison Let's compare the real costs of hosting a React app on Netlify versus a VPS. For this comparison, we'll use a typical scenario: a React app with moderate traffic. ### Scenario: Growing Startup - 200GB bandwidth per month - 50 deploys per month - Build time: 3 minutes per deploy Cost Factor Netlify Pro VPS (Hetzner) Base cost $19/month $4.50/month Bandwidth (200GB) $55 (100GB overage) $0 (20TB included) Build minutes (150 min) Included $0 **Total** **$74/month** **$4.50/month** **Annual cost** **$888/year** **$54/year** ### Scenario: High-Traffic Site - 1TB bandwidth per month - 100 deploys per month - Build time: 5 minutes per deploy Cost Factor Netlify Pro VPS (DigitalOcean) Base cost $19/month $12/month (2GB RAM) Bandwidth (1TB) $495 (900GB overage) $0 (2TB included) Build minutes (500 min) Included $0 **Total** **$514/month** **$12/month** **Annual cost** **$6,168/year** **$144/year** At scale, the difference is staggering. A VPS costs **97% less** than Netlify for high-traffic sites. For a detailed comparison of Netlify alternatives, check out our [Netlify Alternative](/netlify-alternative) page. ### When Netlify Makes Sense To be fair, Netlify offers advantages in certain scenarios: - **Low-traffic sites** — The free tier (100GB bandwidth) is genuinely free - **Team collaboration** — Built-in preview deployments and branch deploys - **Zero DevOps** — No server maintenance whatsoever - **Edge functions** — Serverless functions at the edge However, once you exceed the free tier limits, costs escalate quickly. A VPS gives you predictable costs regardless of traffic. ## Bonus: Automated Deployment Script Create a simple deployment script on your local machine to streamline future deploys: `#!/bin/bash # deploy.sh set -e SERVER="username@your-server-ip" REMOTE_PATH="/var/www/react-app" echo "Building React app..." npm run build echo "Deploying to server..." rsync -avz --delete ./build/ $SERVER:$REMOTE_PATH/ echo "Deployment complete!" echo "Visit: https://yourdomain.com"` Make it executable and run: `chmod +x deploy.sh ./deploy.sh` For more sophisticated CI/CD, consider GitHub Actions that automatically deploy when you push to main. ## Frequently Asked Questions ### Why does React Router show 404 errors on refresh? This happens when Nginx tries to find a file matching the URL path (like `/dashboard`) instead of serving `index.html`. The fix is the `try_files $uri $uri/ /index.html;` directive in your Nginx config, which falls back to `index.html` for all routes, letting React Router handle the routing client-side. ### What VPS size do I need for a React app? A React production build consists of static files (HTML, JS, CSS, images), so minimal resources are needed. The smallest VPS tier (1GB RAM, 1 vCPU) can easily serve millions of requests per month. Nginx is extremely efficient at serving static files. You'd only need to upgrade if you're also running a backend API or database on the same server. ### Can I host multiple React apps on one VPS? Yes! Create separate Nginx server blocks for each domain, each with its own root directory. For example: `# /etc/nginx/sites-available/app1 server { server_name app1.com; root /var/www/app1; # ... } # /etc/nginx/sites-available/app2 server { server_name app2.com; root /var/www/app2; # ... }` ### How do I handle environment variables in production? React apps are client-side, so environment variables must be embedded at build time. Set them before running `npm run build`: `REACT_APP_API_URL=https://api.yourdomain.com npm run build` For Vite, use `VITE_` prefix: `VITE_API_URL=https://api.yourdomain.com npm run build` Remember: never embed secrets in React apps — everything in the bundle is visible to users. ### Why isn't my SSL certificate working? Common issues and solutions: - **DNS not propagated** — Ensure your domain points to your VPS IP. Use `dig yourdomain.com` to verify. - **Firewall blocking port 443** — Run `sudo ufw allow 443` - **Certbot failed** — Check that port 80 is accessible for the HTTP challenge ### How do I verify gzip compression is working? Use curl to check the response headers: `curl -H "Accept-Encoding: gzip" -I https://yourdomain.com/static/js/main.js` Look for `Content-Encoding: gzip`. You can also check in Chrome DevTools: Network tab → select a JS file → Headers → Response Headers. ### Which VPS provider should I use? Popular choices include: - **Hetzner** — Best value, starting at $4/month (20TB bandwidth included) - **DigitalOcean** — Great UX and documentation, $6/month - **Vultr** — Global locations, $5/month - **Linode (Akamai)** — Reliable, $5/month All of these work well for hosting React apps. Choose based on data center locations (pick one close to your users) and your preferred management interface. ### Should I use Docker or deploy directly? Both approaches work well. Direct deployment (copying files to `/var/www`) is simpler and uses fewer resources. Docker adds overhead but provides better isolation, easier rollbacks, and consistency between environments. If you're already using Docker for development or running multiple services, containerizing your React app makes sense. For a simple single-app deployment, direct deployment is often easier. ## Conclusion Deploying a React app to a VPS with Nginx gives you complete control over your hosting environment at a fraction of the cost of managed platforms. With the configuration in this guide, your React app will have: - Proper SPA routing support for React Router - Free SSL certificates with automatic renewal - Gzip compression for faster load times - Aggressive caching for optimal performance - Security headers to protect your users Whether you follow the manual approach or use [Server Compass](/) to automate the process, self-hosting your React app is a smart choice for developers who want predictable costs and full control over their infrastructure. Ready to deploy? Grab a $5 VPS, follow this guide, and have your React app live in under 30 minutes. Or try [Server Compass](/) for a visual deployment experience that handles all the configuration automatically. --- **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'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. --- ## Deploy WordPress on VPS with Docker (Self-Hosted Guide) Source: https://servercompass.app/blog/deploy-wordpress-on-vps-with-docker Published: 2026-03-06 Tags: self-hosted, wordpress, docker, vps-deploy, tutorials Learn how to deploy WordPress on your VPS using Docker and Docker Compose. This comprehensive guide covers MySQL setup, persistent volumes, SSL certificates, backups, and performance optimization for a production-ready self-hosted WordPress site. WordPress powers over 40% of all websites on the internet. From personal blogs to enterprise sites, it remains the most popular content management system in the world. But if you've ever looked at your managed WordPress hosting bill and wondered if there's a better way — there is. Self-hosting WordPress on a VPS gives you complete control over your site, dramatically lower costs, and performance that often exceeds expensive managed solutions. With Docker, the entire deployment becomes reproducible, portable, and easy to manage. This guide walks you through every step to deploy WordPress on your VPS with Docker. By the end, you'll have a production-ready WordPress site with MySQL, persistent storage, SSL certificates, automated backups, and performance optimizations — all running on a $5–$10/month VPS. ## Why Self-Host WordPress on a VPS? Before diving into the technical setup, let's examine why self-hosting WordPress makes sense for developers, agencies, and site owners. ### 1\. Dramatic Cost Savings Managed WordPress hosting typically costs $20–$100/month for a single site. Premium hosts like WP Engine, Kinsta, or Flywheel charge even more for high-traffic sites. Compare that to a VPS: - **Hetzner**: $4–$6/month for 2–4 GB RAM, 40–80 GB NVMe - **DigitalOcean**: $6/month for 1 GB RAM, 25 GB SSD - **Vultr**: $6/month for 1 GB RAM, 25 GB SSD - **Linode**: $5/month for 1 GB RAM, 25 GB SSD A single $6 VPS can host multiple WordPress sites, databases, and even other applications. That's 80–90% savings compared to managed hosting. ### 2\. Full Control Over Your Stack Managed hosts restrict what you can do. You can't install custom PHP extensions, modify server configurations, or run background processes. Self-hosting removes all limitations: - Install any WordPress plugin without restrictions - Use custom PHP versions and extensions (imagick, redis, opcache) - Configure MySQL/MariaDB for your specific workload - Run cron jobs, background workers, or other services - Implement custom caching strategies (Redis, Varnish, Nginx FastCGI) ### 3\. Better Performance Shared managed hosting means your site competes with others for resources. A VPS gives you dedicated CPU, RAM, and NVMe storage. Combined with proper caching and optimization, self-hosted WordPress often outperforms expensive managed solutions. ### 4\. Data Ownership and Privacy Your content, user data, and database stay on servers you control. No third-party access, no data mining, no surprise terms of service changes. For GDPR compliance or sensitive content, this matters. ## Prerequisites Before starting, make sure you have: - **A VPS** with at least 1 GB RAM (2 GB recommended) running Ubuntu 22.04 or Debian 12. Providers like Hetzner, DigitalOcean, Vultr, or Linode all work well. - **A domain name** pointed to your VPS IP address (A record) - **SSH access** to your server (root or sudo user) - **Basic terminal knowledge** (or use [Server Compass](/) to skip the command line entirely) ## Step 1: Set Up Your VPS Start with a fresh VPS installation. After provisioning your server, connect via SSH: ``` ssh root@your-server-ip ``` Update the system packages: ``` apt update && apt upgrade -y ``` For security, create a non-root user and configure SSH key authentication. You should also set up a firewall (UFW) to allow only ports 22 (SSH), 80 (HTTP), and 443 (HTTPS): ``` # Create a new user adduser deploy usermod -aG sudo deploy # Configure UFW firewall ufw allow OpenSSH ufw allow 80/tcp ufw allow 443/tcp ufw enable ``` ## Step 2: Install Docker and Docker Compose Docker simplifies WordPress deployment by packaging the application, PHP, and web server into a single container. Install Docker using the official repository: ``` # Install dependencies apt install -y ca-certificates curl gnupg # Add Docker's official GPG key install -m 0755 -d /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \\ gpg --dearmor -o /etc/apt/keyrings/docker.gpg chmod a+r /etc/apt/keyrings/docker.gpg # Add the repository echo \\ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] \\ https://download.docker.com/linux/ubuntu \\ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \\ tee /etc/apt/sources.list.d/docker.list > /dev/null # Install Docker apt update apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # Verify installation docker --version docker compose version ``` Add your user to the docker group to run commands without sudo: ``` usermod -aG docker deploy ``` ## Step 3: Create WordPress Docker Compose Stack Create a directory for your WordPress project and the Docker Compose configuration: ``` mkdir -p /opt/wordpress cd /opt/wordpress ``` Create the `docker-compose.yml` file: ``` version: '3.8' services: wordpress: image: wordpress:6.4-php8.2-apache container_name: wordpress restart: unless-stopped depends_on: - mysql ports: - "8080:80" environment: WORDPRESS_DB_HOST: mysql:3306 WORDPRESS_DB_NAME: \$ WORDPRESS_DB_USER: \$ WORDPRESS_DB_PASSWORD: \$ WORDPRESS_TABLE_PREFIX: wp_ volumes: - wordpress_data:/var/www/html - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini networks: - wordpress_network mysql: image: mysql:8.0 container_name: wordpress_mysql restart: unless-stopped environment: MYSQL_DATABASE: \$ MYSQL_USER: \$ MYSQL_PASSWORD: \$ MYSQL_ROOT_PASSWORD: \$ volumes: - mysql_data:/var/lib/mysql - ./mysql.cnf:/etc/mysql/conf.d/custom.cnf networks: - wordpress_network command: --default-authentication-plugin=mysql_native_password volumes: wordpress_data: mysql_data: networks: wordpress_network: driver: bridge ``` This configuration defines two services: WordPress (with Apache and PHP 8.2) and MySQL 8.0. The `depends_on` ensures MySQL starts before WordPress. Both services use named volumes for persistent storage and connect through an isolated Docker network. ## Step 4: Configure MySQL/MariaDB Create a `.env` file in the same directory to store your database credentials securely: ``` # /opt/wordpress/.env MYSQL_DATABASE=wordpress MYSQL_USER=wpuser MYSQL_PASSWORD=your_secure_password_here MYSQL_ROOT_PASSWORD=your_root_password_here ``` **Important:** Use strong, randomly generated passwords. You can generate them with: ``` openssl rand -base64 24 ``` Create a custom MySQL configuration file for better performance: ``` # /opt/wordpress/mysql.cnf [mysqld] # InnoDB settings innodb_buffer_pool_size = 256M innodb_log_file_size = 64M innodb_flush_log_at_trx_commit = 2 # Query cache (deprecated in MySQL 8, but useful for MariaDB) # query_cache_type = 1 # query_cache_size = 32M # Connection settings max_connections = 100 wait_timeout = 600 # Logging (disable for production) slow_query_log = 0 ``` If you prefer MariaDB over MySQL, simply change the image in your Docker Compose file: ``` mysql: image: mariadb:10.11 # ... rest of configuration ``` MariaDB is a drop-in replacement for MySQL with better performance in many scenarios. Both work identically with WordPress. ## Step 5: Set Up Persistent Volumes Docker volumes ensure your WordPress files and database survive container restarts, updates, and server reboots. The configuration above already defines named volumes: - `wordpress_data` — Stores WordPress core files, themes, plugins, and uploads - `mysql_data` — Stores the entire MySQL database To increase PHP upload limits for media files, create the `uploads.ini` file: ``` # /opt/wordpress/uploads.ini file_uploads = On memory_limit = 256M upload_max_filesize = 64M post_max_size = 64M max_execution_time = 300 ``` You can verify volume locations with: ``` docker volume inspect wordpress_data ``` By default, volumes are stored in `/var/lib/docker/volumes/`. For production, you might want to back up these directories regularly. ## Step 6: Configure Domain and SSL For production WordPress, you need SSL/TLS (HTTPS). We'll use Traefik as a reverse proxy with automatic Let's Encrypt certificates. Update your `docker-compose.yml`: ``` {`version: '3.8' services: traefik: image: traefik:v2.10 container_name: traefik restart: unless-stopped command: - "--api.dashboard=true" - "--providers.docker=true" - "--providers.docker.exposedbydefault=false" - "--entrypoints.web.address=:80" - "--entrypoints.websecure.address=:443" - "--certificatesresolvers.letsencrypt.acme.httpchallenge=true" - "--certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web" - "--certificatesresolvers.letsencrypt.acme.email=your-email@example.com" - "--certificatesresolvers.letsencrypt.acme.storage=/letsencrypt/acme.json" - "--entrypoints.web.http.redirections.entrypoint.to=websecure" - "--entrypoints.web.http.redirections.entrypoint.scheme=https" ports: - "80:80" - "443:443" volumes: - /var/run/docker.sock:/var/run/docker.sock:ro - letsencrypt:/letsencrypt networks: - wordpress_network wordpress: image: wordpress:6.4-php8.2-apache container_name: wordpress restart: unless-stopped depends_on: - mysql environment: WORDPRESS_DB_HOST: mysql:3306 WORDPRESS_DB_NAME: \$ WORDPRESS_DB_USER: \$ WORDPRESS_DB_PASSWORD: \$ WORDPRESS_TABLE_PREFIX: wp_ volumes: - wordpress_data:/var/www/html - ./uploads.ini:/usr/local/etc/php/conf.d/uploads.ini networks: - wordpress_network labels: - "traefik.enable=true" - "traefik.http.routers.wordpress.rule=Host(\`yourdomain.com\`)" - "traefik.http.routers.wordpress.entrypoints=websecure" - "traefik.http.routers.wordpress.tls.certresolver=letsencrypt" - "traefik.http.services.wordpress.loadbalancer.server.port=80" mysql: image: mysql:8.0 container_name: wordpress_mysql restart: unless-stopped environment: MYSQL_DATABASE: \$ MYSQL_USER: \$ MYSQL_PASSWORD: \$ MYSQL_ROOT_PASSWORD: \$ volumes: - mysql_data:/var/lib/mysql - ./mysql.cnf:/etc/mysql/conf.d/custom.cnf networks: - wordpress_network command: --default-authentication-plugin=mysql_native_password volumes: wordpress_data: mysql_data: letsencrypt: networks: wordpress_network: driver: bridge`} ``` Replace `yourdomain.com` with your actual domain and update the email address for Let's Encrypt notifications. Traefik will automatically obtain and renew SSL certificates. Now start the stack: ``` cd /opt/wordpress docker compose up -d ``` Verify all containers are running: ``` docker compose ps ``` You should see three containers (traefik, wordpress, wordpress\_mysql) all showing "running" status. ## Step 7: WordPress Initial Setup Navigate to `https://yourdomain.com` in your browser. You'll see the WordPress installation wizard: 1. Select your language 2. Enter your site title, admin username, password, and email 3. Click "Install WordPress" After installation, log in to the WordPress admin at `https://yourdomain.com/wp-admin`. **Post-installation security steps:** - Delete the default "Hello World" post and sample page - Update permalinks to a SEO-friendly structure (Settings → Permalinks → Post name) - Install a security plugin like Wordfence or Solid Security - Disable XML-RPC if you don't need it (reduces attack surface) - Enable two-factor authentication for admin accounts ## Step 8: Automated Backups with Docker A WordPress site without backups is a disaster waiting to happen. Create a backup script that exports both the database and WordPress files: ``` #!/bin/bash # /opt/wordpress/backup.sh # Configuration BACKUP_DIR="/opt/backups/wordpress" DATE=$(date +%Y-%m-%d_%H-%M-%S) RETENTION_DAYS=7 # Create backup directory mkdir -p $BACKUP_DIR # Backup MySQL database docker exec wordpress_mysql mysqldump -u root -p\$ \\ --all-databases --single-transaction > $BACKUP_DIR/db_$DATE.sql # Backup WordPress files docker run --rm -v wordpress_data:/data -v $BACKUP_DIR:/backup \\ alpine tar czf /backup/files_$DATE.tar.gz -C /data . # Compress database dump gzip $BACKUP_DIR/db_$DATE.sql # Remove backups older than retention period find $BACKUP_DIR -name "*.sql.gz" -mtime +$RETENTION_DAYS -delete find $BACKUP_DIR -name "*.tar.gz" -mtime +$RETENTION_DAYS -delete echo "Backup completed: $DATE" ``` Make the script executable and add it to cron for daily backups: ``` chmod +x /opt/wordpress/backup.sh # Add to crontab (runs daily at 3 AM) crontab -e # Add this line: 0 3 * * * /opt/wordpress/backup.sh >> /var/log/wordpress-backup.log 2>&1 ``` For off-site backups, you can sync the backup directory to S3, Backblaze B2, or any S3-compatible storage using `rclone` or the AWS CLI. ## Step 9: Performance Optimization A self-hosted WordPress site can be incredibly fast with the right optimizations. ### Enable Redis Object Caching Add Redis to your Docker Compose stack for persistent object caching: ``` redis: image: redis:7-alpine container_name: wordpress_redis restart: unless-stopped networks: - wordpress_network volumes: - redis_data:/data ``` Add `redis_data:` to your volumes section, then install the Redis Object Cache plugin in WordPress and configure it to connect to `wordpress_redis:6379`. ### Enable PHP OPcache OPcache dramatically improves PHP performance by caching compiled scripts. Add to your `uploads.ini`: ``` opcache.enable=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=10000 opcache.revalidate_freq=60 opcache.fast_shutdown=1 ``` ### Robots.txt for SEO Don't forget to configure your `robots.txt` file — it controls which pages search engines and AI crawlers can access. WordPress generates a basic one, but for fine-grained control use our [free robots.txt generator](/tools/robots-txt-generator) to block admin pages, manage crawl rates, and protect sensitive paths. ### CDN Integration Use Cloudflare (free tier) as a CDN and DDoS protection layer. Point your domain's nameservers to Cloudflare, and they'll cache static assets globally. Plugins like WP Super Cache or W3 Total Cache can further optimize caching. ### Image Optimization Install Imagify, ShortPixel, or Smush to automatically compress uploaded images. Consider serving images in WebP format for modern browsers. ## Cost Comparison: Managed WordPress vs VPS Let's compare the real costs of running WordPress: Hosting Type Monthly Cost Sites Included Storage Bandwidth WP Engine (Startup) $20 1 site 10 GB 50 GB Kinsta (Starter) $30 1 site 10 GB 25k visits Flywheel (Tiny) $15 1 site 5 GB 20 GB SiteGround (StartUp) $15 1 site 10 GB ~10k visits **Hetzner VPS (CX21)** **$5** **Unlimited** **40 GB NVMe** **20 TB** **DigitalOcean Droplet** **$6** **Unlimited** **25 GB SSD** **1 TB** The difference becomes even more dramatic when hosting multiple sites. A single $6 VPS can run 5–10 low-traffic WordPress sites easily. Try doing that on managed hosting without spending $100+/month. **Annual savings with self-hosting:** - vs WP Engine: $180/year saved - vs Kinsta: $288/year saved - vs Flywheel: $108/year saved Multiply by the number of sites you manage, and the savings become substantial. ## One-Click Deploy with Server Compass All of the above steps work perfectly, but they require SSH access, terminal commands, and manual configuration. If you prefer a visual interface, [Server Compass](/) can deploy WordPress to your VPS in about 60 seconds. ![Server Compass template gallery showing WordPress deployment template](/app-screenshots/feature-templates.jpg) Here's how it works: 1. **Connect your VPS** — Add your server with SSH credentials in Server Compass 2. **Open the template gallery** — Click **New App** → **From Template** and search for [WordPress](/templates/wordpress) 3. **Configure and deploy** — Set your database credentials, domain, and click Deploy Server Compass handles Docker installation, MySQL setup, Traefik configuration, SSL certificates, and persistent volumes automatically. You get the same production-ready setup described in this guide without writing a single terminal command. The template gallery includes 100+ pre-configured stacks including [MySQL](/templates/mysql), [MariaDB](/templates/mariadb), [Traefik](/features/domain-management), and [Redis](/templates/redis) — everything you need for a complete WordPress stack. Additional features that help with WordPress management: - [Container status monitoring](/features/container-status) — See real-time CPU, memory, and health status - [Container logs](/features/container-logs) — Debug issues without SSH - [Automated backups](/features/server-backups) — Schedule backups to S3-compatible storage - [Environment vault](/features/env-vault) — Securely store database passwords - [Firewall management](/features/ufw-firewall) — Configure UFW rules visually ## Frequently Asked Questions ### What VPS size do I need for WordPress? For a single low-to-medium traffic site (under 50k monthly visitors), 1 GB RAM is sufficient. For multiple sites or higher traffic, choose 2–4 GB RAM. The Hetzner CX21 (2 vCPU, 4 GB RAM, $5.50/month) handles most WordPress workloads comfortably. ### Should I use MySQL or MariaDB? Both work identically with WordPress. MariaDB often performs slightly better and is fully open-source. MySQL 8.0 has some enterprise features. For most WordPress sites, the difference is negligible. Use whichever you're more comfortable with. ### How do I update WordPress in Docker? WordPress core updates work through the admin dashboard as usual. To update the Docker image (for PHP/Apache updates), pull the new image and recreate the container: ``` docker compose pull wordpress docker compose up -d --force-recreate wordpress ``` Your WordPress files and database are stored in volumes, so they persist across container updates. ### Can I run WordPress Multisite with this setup? Yes. Enable multisite in `wp-config.php` after installation. For subdomain multisite, you'll need wildcard SSL certificates (Traefik supports this via DNS challenge with supported providers). ### How do I send emails from WordPress? Docker containers don't include a mail server. Use an SMTP plugin (WP Mail SMTP, FluentSMTP) with a transactional email service like Mailgun, SendGrid, Amazon SES, or Brevo. These services offer free tiers for low-volume sending. ### Is self-hosted WordPress secure? Self-hosted WordPress is as secure as you make it. Follow best practices: keep WordPress, plugins, and themes updated; use strong passwords; install a security plugin; configure your firewall properly; and enable fail2ban for SSH protection. Server Compass includes a [security audit](/features/security-audit) feature that checks for common misconfigurations. ### How do I migrate an existing WordPress site? Use a migration plugin like All-in-One WP Migration, Duplicator, or UpdraftPlus. Export your site from the old host, deploy a fresh WordPress on your VPS, and import the backup. Update your domain's DNS to point to the new server after verifying everything works. ### How do I set up a staging environment? Create a second WordPress stack with a different container name and subdomain (e.g., `staging.yourdomain.com`). Use plugins like WP Staging to sync production to staging when needed. ## Conclusion Deploying WordPress on a VPS with Docker gives you the best of both worlds: the flexibility and cost savings of self-hosting with the simplicity of containerized deployment. Your entire stack is defined in a single `docker-compose.yml` file that's easy to version control, replicate, and migrate. Whether you follow the manual steps in this guide or use [Server Compass](/) for one-click deployment, you'll end up with a production-ready WordPress site that costs 80% less than managed hosting while giving you complete control over your infrastructure. Ready to deploy WordPress on your VPS? [Try Server Compass](/) — $29 one-time, no subscription, no usage fees. Or bookmark this guide and follow the manual steps whenever you're ready. --- **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'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. --- ## Fly.io Pricing Breakdown: $40/mo vs $5 VPS (2026) Source: https://servercompass.app/blog/flyio-pricing-breakdown-vs-vps Published: 2026-03-06 Complete Fly.io pricing breakdown for 2026. Learn how Machines, volumes, bandwidth, and dedicated IPs add up. Compare real costs vs self-hosting on a $5 VPS with Server Compass. TL;DR A production app on Fly.io costs **$20–40+/mo** with Machines, volumes, bandwidth, and IPs billed separately. Server Compass lets you self-host on a **$5 VPS** with a one-time $29 payment — one price for everything. [Try Server Compass free →](/) Fly.io has positioned itself as the go-to platform for developers who want global edge deployment without managing Kubernetes. The promise is compelling: deploy your Docker containers to data centers around the world with a simple CLI command. But when you dig into the **Fly.io pricing** model, the reality becomes more complex. Unlike traditional VPS providers with fixed monthly rates, Fly.io uses a resource-based pricing model where you pay for CPU, RAM, storage, bandwidth, and IP addresses separately. This can make it difficult to predict your actual monthly bill until you're already running in production. In this comprehensive breakdown, we'll explain exactly how **Fly.io pricing** works, calculate real-world costs for common deployments, and compare them against what you'd pay for a simple $5 VPS. By the end, you'll know exactly when Fly.io makes sense and when self-hosting is the smarter choice. ## How Fly.io Pricing Works Fly.io's pricing is built around “Machines” — their term for the containers that run your applications. Unlike a VPS where you pay one price for a bundle of resources, Fly.io charges separately for each component. Let's break down every billable item. ### Machines (CPU and RAM) Machines are the core compute unit on Fly.io. Each Machine runs your Docker container and is billed per second based on CPU and RAM allocation. Here's the current pricing structure: Machine Type CPU RAM Per Hour Per Month (730hrs) shared-cpu-1x 1 shared 256MB $0.0027 $1.94 shared-cpu-1x 1 shared 512MB $0.0041 $2.99 shared-cpu-1x 1 shared 1GB $0.0068 $4.97 shared-cpu-2x 2 shared 2GB $0.0191 $13.94 performance-1x 1 dedicated 2GB $0.0536 $39.13 performance-2x 2 dedicated 4GB $0.1072 $78.26 performance-4x 4 dedicated 8GB $0.2144 $156.51 **Key insight:** The cheapest shared CPU option is $1.94/month, but with only 256MB RAM, it's barely enough for a static site. Most real applications need at least 512MB-1GB, pushing you to $3-5/month per Machine just for compute. ### Volumes (Persistent Storage) Fly Machines are ephemeral by default — when they restart, any data written to the filesystem is lost. If you need persistent storage (and you almost certainly do for databases, file uploads, or any stateful application), you'll need Fly Volumes. Resource Price Monthly Cost (10GB) Volume Storage $0.15/GB/month $1.50 Volume Storage (50GB) $0.15/GB/month $7.50 Volume Storage (100GB) $0.15/GB/month $15.00 While $0.15/GB sounds cheap, remember that most $5 VPS plans include 25-80GB of SSD storage. On Fly.io, getting equivalent storage would cost $3.75-12/month on top of your compute costs. ### Bandwidth (Outbound Data Transfer) Fly.io includes some bandwidth in each region, but charges for overages. The pricing varies by region: Region Included Overage Price North America & Europe 100GB/month $0.02/GB Asia Pacific 30GB/month $0.04/GB India 30GB/month $0.12/GB Africa & South America 30GB/month $0.06/GB For most small to medium applications in North America or Europe, 100GB of included bandwidth is generous. But if you're serving media files, large downloads, or have globally distributed traffic, bandwidth costs can add up quickly. ### Dedicated IPv4 Addresses Here's a cost that catches many developers off guard: **dedicated IPv4 addresses cost $2/month each**. While Fly.io provides shared IPv4 and IPv6 for free, certain use cases require dedicated IPs: - Running services that require a static IP - Setting up custom DNS configurations - Complying with IP whitelisting requirements - Running multiple apps that need separate IPs On a VPS, you get a dedicated IPv4 address included in your plan. On Fly.io, that's an extra $2/month per IP. ### Managed Postgres Fly.io offers managed PostgreSQL, which is convenient but adds to your bill: Plan Resources Monthly Cost Development 1 shared CPU, 256MB RAM, 1GB storage ~$2/month Production (single node) 1 shared CPU, 1GB RAM, 10GB storage ~$7/month Production (HA) 2 replicas + 10GB storage ~$15-30/month Compare this to self-hosting PostgreSQL on a VPS: the database runs alongside your app at no extra cost beyond the VPS itself. ## Real Cost Examples Now let's calculate what you'd actually pay for common deployment scenarios on Fly.io versus a traditional VPS. ### Example 1: Simple Web App (Node.js/Next.js) A typical Node.js or Next.js application with modest traffic (under 10,000 requests/day). Component Fly.io Cost VPS Cost Compute (shared-cpu-1x, 1GB RAM) $4.97/mo Included Storage (10GB volume) $1.50/mo Included (25-80GB) Bandwidth (50GB) $0 (under limit) Included (1-4TB) IPv4 Address $0 (shared) or $2/mo Included Total $6.47-8.47/mo $5/mo **Result:** Even for the simplest app, Fly.io costs 30-70% more than a basic VPS. ### Example 2: App with Database A web application with a PostgreSQL database — the most common production setup. Component Fly.io Cost VPS Cost App Machine (shared-cpu-1x, 1GB) $4.97/mo Included Postgres Machine $4.97/mo Included (Docker) App Volume (5GB) $0.75/mo Included Postgres Volume (20GB) $3.00/mo Included Bandwidth (100GB) $0 Included Dedicated IPv4 $2/mo Included Total $15.69/mo $5-6/mo **Result:** With a database, Fly.io costs **2.5-3x more** than a VPS running the same stack. That's $115/year in extra costs. ### Example 3: Multi-Region Deployment This is where Fly.io's value proposition shines — deploying to multiple regions for low latency globally. But let's see the costs: Component Fly.io Cost (3 regions) 3x App Machines (shared-cpu-1x, 1GB each) $14.91/mo Primary Postgres + 2 Read Replicas $14.91/mo 3x Volumes (20GB each) $9.00/mo Bandwidth (cross-region traffic) $5-15/mo (estimate) Dedicated IPv4 $2/mo Total $45.82-55.82/mo For true multi-region deployment, Fly.io is actually competitive. Setting up the same infrastructure yourself would require 3 VPS instances ($15-20/month) plus database replication configuration, load balancing, and significant DevOps expertise. However, most applications don't need multi-region deployment. If your users are primarily in one geographic area, a single well-placed VPS delivers excellent performance. ## Fly.io vs VPS: Complete Cost Comparison Here's a comprehensive comparison for different use cases: Use Case Fly.io Monthly VPS Monthly Annual Savings Static site / simple app $5-8 $5 $0-36 Web app + PostgreSQL $15-20 $5-6 $108-180 Full stack (app + DB + Redis) $20-30 $6-12 $168-216 Production app (dedicated CPU) $40-80 $12-24 $336-672 Multi-region (3 locations) $45-60 $15-20 (3x VPS) $360-480\* \*Multi-region VPS requires additional setup for load balancing and replication. ## When Fly.io Makes Sense Despite the higher costs, Fly.io is the right choice in specific scenarios: ### 1\. Global Low Latency is Critical If your application serves users worldwide and milliseconds matter (real-time collaboration, gaming, financial applications), Fly.io's global edge network provides genuine value. Deploying to 20+ regions with a single command is something you simply can't replicate easily with VPS infrastructure. ### 2\. You Need Geographic Redundancy For applications requiring high availability across multiple continents, Fly.io handles the complexity of multi-region deployment, database replication, and automatic failover. Building this yourself requires significant DevOps expertise. ### 3\. Your Traffic is Highly Variable Fly.io's per-second billing and automatic scaling can be cost-effective if you have traffic that spikes dramatically. A VPS sits idle during low-traffic periods but costs the same. Fly.io Machines can scale to zero (though wake time affects user experience). ### 4\. You Value CLI-First Workflow The `flyctl` CLI is excellent. If you prefer deploying via terminal commands and want tight integration with your Git workflow, Fly.io's developer experience is top-notch. ## When VPS Wins For the majority of applications, a VPS provides better value: ### 1\. Single-Region Deployment If your users are concentrated in one geographic area (most B2B SaaS, regional businesses, personal projects), a single VPS in that region delivers the same performance at a fraction of the cost. A VPS in Frankfurt serves European users just as well as a Fly.io Machine in Frankfurt — but costs 50-70% less. ### 2\. Predictable Workloads When your traffic is steady and predictable, fixed VPS pricing beats resource-based billing. You know exactly what you'll pay each month — no surprise bills from traffic spikes or bandwidth overages. ### 3\. Multiple Services on One Server A VPS lets you run your app, database, Redis, cron jobs, and monitoring tools on a single $5-10 server. On Fly.io, each service is a separate billable Machine. Running PostgreSQL, Redis, and your app together on Fly.io easily costs $15-25/month. The same stack on a VPS: $5-10/month. ### 4\. Cost-Conscious Projects Side projects, MVPs, startups watching their runway, and indie developers benefit from VPS economics. The annual savings of $100-500+ compounds over time and across multiple projects. ### 5\. Full Infrastructure Control With a VPS, you have root access. Install any software, configure the OS however you want, run long-running processes, access full system logs, and debug issues directly on the server. Fly.io's container abstraction hides this complexity — which is great until you need to troubleshoot at the system level. ## Alternative: Server Compass + VPS What if you could get Fly.io's deployment experience with VPS economics? That's exactly what [Server Compass](/) delivers. Server Compass is a desktop application that gives you visual deployment tools for your own VPS. Instead of paying Fly.io's resource-based pricing, you pay a one-time $29 license plus your VPS cost ($5-10/month for most applications). ### What You Get - **[One-click Docker deployments](/features/docker-stack-wizard)** — Deploy containers visually without writing Docker commands - **[Git-based auto-deploy](/features/auto-deploy)** — Push to GitHub, auto-deploy to your VPS (just like Fly.io) - **[Zero-downtime deployments](/features/zero-downtime)** — Blue-green deployments with automatic rollback - **[Automatic SSL](/features/auto-ssl)** — Let's Encrypt certificates provisioned automatically - **[166+ one-click templates](/templates)** — Deploy PostgreSQL, Redis, MongoDB, and more instantly - **[.env Vault](/features/env-vault)** — AES-256-GCM encrypted environment variables - **No server footprint** — Server Compass runs on your desktop, not on your VPS ![Server Compass container management dashboard showing running containers with CPU and memory monitoring](/app-screenshots/feature-container-status.jpg) ### Cost Comparison Summary Scenario Fly.io (Annual) Server Compass + VPS You Save App + PostgreSQL $180-240/year $29 + $60/year = $89 $91-151 Full stack $240-360/year $29 + $72/year = $101 $139-259 Production (dedicated CPU) $480-960/year $29 + $144/year = $173 $307-787 For detailed feature comparisons, see our [Server Compass vs Fly.io comparison](/compare/flyio) and [Fly.io alternative](/flyio-alternative) pages. ## Frequently Asked Questions ### Does Fly.io have a free tier? Fly.io offers a $5 monthly credit for new accounts, which covers roughly 2-3 small Machines. However, this isn't a true free tier — it's a credit that gets consumed by usage. Once depleted, you pay full price. The free tier is best suited for testing and development, not production workloads. ### What are Fly.io's hidden costs? The most commonly overlooked costs are: - **Dedicated IPv4:** $2/month (required for many setups) - **Volumes:** $0.15/GB/month for persistent storage - **Regional bandwidth:** Asia, India, Africa have lower included bandwidth and higher overage rates - **Multiple Machines:** Each database, cache, or worker is a separate billable Machine ### Can Fly.io scale to zero? Yes, Fly.io Machines can scale to zero when not receiving traffic, which stops compute charges. However, there are important caveats: - Cold start latency when the Machine wakes up (1-3 seconds typically) - Volume storage continues to be billed even when Machines are stopped - Databases should not scale to zero as they need to be always available ### What's cheaper than Fly.io? For single-region deployments, almost any VPS provider is cheaper: - **Hetzner:** $4.15/month for 2 vCPU, 4GB RAM, 40GB SSD - **DigitalOcean:** $6/month for 1 vCPU, 1GB RAM, 25GB SSD - **Vultr:** $5/month for 1 vCPU, 1GB RAM, 25GB SSD - **Linode:** $5/month for 1 vCPU, 1GB RAM, 25GB SSD Pair any of these with [Server Compass](/) ($29 one-time) for a deployment experience comparable to Fly.io at a fraction of the ongoing cost. ### How hard is it to migrate from Fly.io to VPS? Migration is straightforward because Fly.io uses standard Docker containers. Your existing Dockerfile works unchanged on a VPS. The main steps are: 1. Export your database from Fly.io Postgres 2. Spin up a VPS (takes 60 seconds) 3. Deploy your Docker container using Server Compass or docker-compose 4. Import your database 5. Update DNS to point to your new VPS IP Most migrations complete in under an hour. ### Is Fly.io faster than a VPS? For single-region deployments, performance is comparable. A Fly.io Machine in Frankfurt and a Hetzner VPS in Frankfurt have similar latency for European users. Fly.io's advantage is *multi-region* deployment — serving users from the closest edge location. If you don't need global distribution, a well-placed VPS performs just as well. ## Conclusion **Fly.io pricing** makes sense for specific use cases: global edge deployment, multi-region redundancy, and applications with highly variable traffic. For these scenarios, the convenience and built-in infrastructure justify the premium. For everyone else — single-region apps, startups, side projects, and cost-conscious developers — a $5-10 VPS delivers the same (or better) results at 50-70% lower cost. Tools like [Server Compass](/) bridge the deployment experience gap, giving you Fly.io-like convenience while keeping your infrastructure costs minimal. The bottom line: unless you're building a globally distributed application, self-hosting on a VPS will save you $100-500+ per year with no meaningful compromise in performance or developer experience. Ready to switch? [Try Server Compass](/) — $29 one-time, deploy unlimited apps to unlimited servers, and stop paying Fly.io's resource-based premiums. --- **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. --- ## How to Deploy a Node.js App on a VPS (Beginner Guide) Source: https://servercompass.app/blog/how-to-deploy-nodejs-app-on-vps Published: 2026-03-06 Tags: nodejs, deployment, vps-deploy, tutorials, self-hosted Learn how to deploy your Node.js application on a VPS step by step. This beginner-friendly guide covers SSH setup, Node.js installation, PM2 process management, Nginx reverse proxy, SSL certificates, and firewall configuration. Deploying a Node.js application to a Virtual Private Server (VPS) might seem intimidating if you've only used platforms like Vercel, Railway, or Heroku. But here's the truth: once you understand the basics, VPS deployment gives you more control, better performance, and significantly lower costs. In this comprehensive guide, you'll learn how to deploy a Node.js app on a VPS from scratch. We'll cover everything from connecting via SSH to setting up a production-ready environment with PM2, Nginx, SSL certificates, and firewall rules. By the end of this tutorial, your Node.js application will be running on your own server, secured with HTTPS, and ready to handle real traffic. ## Why Deploy Node.js on a VPS Instead of PaaS? Platform-as-a-Service (PaaS) providers like Vercel, Railway, and Render offer convenience — push your code and they handle the rest. But that convenience comes at a price, both literally and figuratively. ### Cost Savings Let's do the math. A basic Node.js app on Railway or Render costs $5-15/month. Add a database, and you're at $15-30/month. Scale to handle more traffic, and costs climb quickly to $50-100+/month. A VPS from providers like Hetzner, DigitalOcean, or Vultr costs $4-10/month for a server with 2-4GB RAM, 2 vCPUs, and 40-80GB of SSD storage. That single server can run your Node.js app, database, Redis cache, and multiple other services — all for less than the cheapest PaaS tier. Over a year, you could save $200-500 or more. For indie developers and startups, that money goes a long way. ### Full Control Over Your Environment On a VPS, you control everything: - **Node.js version** — Run any version you need, including LTS and experimental releases - **System dependencies** — Install native modules, image processing libraries, or any Linux package - **Server configuration** — Tune your environment for your specific workload - **Data location** — Choose where your data physically lives for compliance and latency - **No cold starts** — Your app runs continuously, ready to serve requests instantly ### No Vendor Lock-in PaaS platforms often introduce subtle dependencies: proprietary environment variables, platform-specific APIs, unique deployment configurations. When you need to migrate, you're rewriting infrastructure code. A VPS deployment uses standard tools — Node.js, PM2, Nginx, and systemd. Move to any other VPS provider, and your deployment process stays the same. ## Prerequisites Before we begin, make sure you have the following: - **A VPS running Ubuntu 22.04 or 24.04** — You can use any Linux distribution, but this guide assumes Ubuntu. Get one from [Hetzner](https://www.hetzner.com/cloud) , [DigitalOcean](https://www.digitalocean.com) , [Vultr](https://www.vultr.com) , or any other provider. A $5-10/month plan is sufficient for most apps. - **A Node.js application ready to deploy** — This can be an Express, Fastify, NestJS, or any other Node.js framework. Your app should have a `package.json` and a start script. - **SSH access to your server** — Your VPS provider will give you an IP address and either a root password or SSH key. - **A domain name (optional but recommended)** — For SSL certificates and professional deployment. - **Basic terminal knowledge** — You should be comfortable running commands in a terminal. If you're starting from scratch, create a simple Express app locally that we'll use throughout this tutorial: ``` {`# Create a new directory mkdir my-node-app && cd my-node-app # Initialize the project npm init -y # Install Express npm install express # Create the main file cat > index.js << 'EOF' const express = require('express'); const app = express(); const PORT = process.env.PORT || 3000; app.get('/', (req, res) => { res.json({ message: 'Hello from my VPS!', timestamp: new Date().toISOString() }); }); app.get('/health', (req, res) => { res.status(200).json({ status: 'healthy' }); }); app.listen(PORT, () => { console.log(\`Server running on port \$\`); }); EOF`} ``` Push this to a Git repository (GitHub, GitLab, or any Git hosting) so we can clone it on the server. ## Step 1: Connect to Your VPS via SSH SSH (Secure Shell) is how you'll access your server's command line remotely. When you create a VPS, your provider gives you an IP address and credentials. ### Connecting with a Password If your provider gave you a root password, connect like this: ``` ssh root@your-server-ip ``` Replace `your-server-ip` with your actual server IP address (e.g., `203.0.113.50`). You'll be prompted to enter the password. ### Connecting with an SSH Key (Recommended) SSH keys are more secure than passwords. If you set up an SSH key when creating your VPS, connect like this: ``` ssh -i ~/.ssh/your-key root@your-server-ip ``` If your key is the default `~/.ssh/id_rsa` or `~/.ssh/id_ed25519`, you can simply use: ``` ssh root@your-server-ip ``` ### First-Time Connection The first time you connect, you'll see a message asking you to verify the server's fingerprint: ``` The authenticity of host 'your-server-ip' can't be established. ED25519 key fingerprint is SHA256:xxxxxxxxxxxxx. Are you sure you want to continue connecting (yes/no)? ``` Type `yes` and press Enter. This adds the server to your known hosts so you won't see this message again. ### Create a Non-Root User (Security Best Practice) Running everything as root is risky. Let's create a dedicated user for your application: ``` # Create a new user (replace 'deploy' with your preferred username) adduser deploy # Add the user to the sudo group usermod -aG sudo deploy # Switch to the new user su - deploy ``` From now on, we'll run commands as this user. When you need root privileges, prefix commands with `sudo`. ## Step 2: Install Node.js and npm Using nvm The best way to install Node.js on a server is with **nvm (Node Version Manager)**. It lets you install multiple Node versions and switch between them easily — perfect for managing different projects or upgrading Node.js later. ### Install nvm ``` # Download and install nvm curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash # Load nvm into your current session export NVM_DIR="$HOME/.nvm" [ -s "$NVM_DIR/nvm.sh" ] && \\. "$NVM_DIR/nvm.sh" # Verify nvm is installed nvm --version ``` You should see a version number like `0.40.1`. ### Install Node.js ``` # Install the latest LTS version of Node.js nvm install --lts # Verify installation node --version npm --version ``` You should see something like `v22.x.x` for Node and `10.x.x` for npm (versions may vary). ### Set the Default Node Version Make sure this Node version is used whenever you log in: ``` nvm alias default node ``` ## Step 3: Clone Your Application Now let's get your application code onto the server. We'll clone it from Git. ### Install Git (if not already installed) ``` sudo apt update sudo apt install -y git ``` ### Clone Your Repository ``` # Navigate to the home directory cd ~ # Clone your repository (replace with your actual repo URL) git clone https://github.com/yourusername/my-node-app.git # Enter the project directory cd my-node-app ``` For private repositories, you'll need to set up SSH keys on the server or use a personal access token: ``` # For private repos with token (GitHub) git clone https://your-token@github.com/yourusername/my-node-app.git # Or set up SSH keys for the deploy user ssh-keygen -t ed25519 -C "deploy@yourserver" cat ~/.ssh/id_ed25519.pub # Add this public key to your GitHub/GitLab account ``` ## Step 4: Install Dependencies and Build With your code on the server, install dependencies and build your application. ### Install Dependencies ``` # Make sure you're in your project directory cd ~/my-node-app # Install production dependencies npm ci --production # Or if you need dev dependencies for building npm ci ``` Using `npm ci` instead of `npm install` ensures your dependencies match the exact versions in `package-lock.json`, making deployments reproducible. ### Build Your Application (If Needed) If your app has a build step (TypeScript compilation, bundling, etc.): ``` # Run the build script npm run build # If you have TypeScript npx tsc ``` ### Test the Application Before setting up process management, verify your app runs: ``` # Start your app npm start # Or if your entry point is different node index.js ``` You should see output like `Server running on port 3000`. Press `Ctrl+C` to stop it. ## Step 5: Set Up PM2 for Process Management Running your app with `node index.js` works for testing, but it has problems in production: - The app stops if you close your SSH session - If the app crashes, it stays down - No logging or monitoring - Can't utilize multiple CPU cores **PM2** solves all of these. It's a production-grade process manager for Node.js that handles automatic restarts, clustering, logging, and startup scripts. ### Install PM2 Globally ``` npm install -g pm2 ``` ### Start Your App with PM2 ``` # Start the application pm2 start index.js --name "my-node-app" # Or if you have a start script in package.json pm2 start npm --name "my-node-app" -- start ``` You should see a table showing your app's status: ``` ┌─────┬──────────────┬─────────────┬─────────┬─────────┬──────────┐ │ id │ name │ namespace │ version │ mode │ pid │ ├─────┼──────────────┼─────────────┼─────────┼─────────┼──────────┤ │ 0 │ my-node-app │ default │ 1.0.0 │ fork │ 12345 │ └─────┴──────────────┴─────────────┴─────────┴─────────┴──────────┘ ``` ### Essential PM2 Commands ``` # View running processes pm2 list # View logs pm2 logs my-node-app # Monitor CPU and memory in real-time pm2 monit # Restart the application pm2 restart my-node-app # Stop the application pm2 stop my-node-app # Delete from PM2 (doesn't delete files) pm2 delete my-node-app ``` ### Create an Ecosystem File (Advanced Configuration) For more control, create a PM2 ecosystem file: ``` cat > ecosystem.config.js << 'EOF' module.exports = { apps: [{ name: 'my-node-app', script: 'index.js', instances: 'max', // Use all CPU cores exec_mode: 'cluster', // Enable clustering env: { NODE_ENV: 'production', PORT: 3000 }, env_production: { NODE_ENV: 'production', PORT: 3000 }, max_memory_restart: '500M', // Restart if memory exceeds 500MB log_date_format: 'YYYY-MM-DD HH:mm:ss', error_file: '/home/deploy/logs/my-node-app-error.log', out_file: '/home/deploy/logs/my-node-app-out.log', merge_logs: true }] } EOF # Create logs directory mkdir -p ~/logs # Start using the ecosystem file pm2 start ecosystem.config.js --env production ``` ### Configure PM2 to Start on Boot Make sure your app survives server reboots: ``` # Generate startup script pm2 startup systemd # PM2 will output a command to run with sudo - copy and run it # It looks like: sudo env PATH=$PATH:/home/deploy/.nvm/versions/node/v22.x.x/bin pm2 startup systemd -u deploy --hp /home/deploy # Save the current PM2 process list pm2 save ``` Now PM2 will automatically start your app when the server boots. ## Step 6: Configure Nginx as a Reverse Proxy Your Node.js app is running on port 3000, but you want users to access it on port 80 (HTTP) and 443 (HTTPS). Nginx serves as a reverse proxy — it receives requests on standard ports and forwards them to your Node.js app. Nginx also provides benefits like: - Serving static files efficiently - SSL/TLS termination - Load balancing (if you have multiple app instances) - Compression and caching - Protection against certain attacks ### Install Nginx ``` sudo apt update sudo apt install -y nginx ``` ### Create an Nginx Configuration Create a new site configuration for your app: ``` sudo nano /etc/nginx/sites-available/my-node-app ``` Add the following configuration (replace `yourdomain.com` with your actual domain, or use your server's IP address): ``` server { listen 80; listen [::]:80; server_name yourdomain.com www.yourdomain.com; location / { proxy_pass http://127.0.0.1:3000; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; proxy_read_timeout 86400s; proxy_send_timeout 86400s; } } ``` **Pro tip:** Use our [Nginx Config Generator](/tools/nginx-config-generator) tool to create optimized configurations for your specific setup — including SSL, caching, WebSocket support, and more. Also create a [robots.txt file](/tools/robots-txt-generator) to control how search engines crawl your Node.js app. ### Enable the Site ``` # Create a symbolic link to enable the site sudo ln -s /etc/nginx/sites-available/my-node-app /etc/nginx/sites-enabled/ # Remove the default site (optional) sudo rm /etc/nginx/sites-enabled/default # Test Nginx configuration sudo nginx -t # If the test passes, reload Nginx sudo systemctl reload nginx ``` You should see `nginx: configuration file /etc/nginx/nginx.conf test is successful`. ### Test the Configuration Open your browser and navigate to `http://yourdomain.com` or `http://your-server-ip`. You should see your Node.js app's response. If you get a 502 Bad Gateway error, make sure your Node.js app is running with PM2 and listening on port 3000. ## Step 7: Set Up SSL with Let's Encrypt HTTPS is essential for production applications. It encrypts traffic between users and your server, builds trust, and is required for many modern web features. Let's Encrypt provides free SSL certificates that auto-renew. ### Install Certbot Certbot is the official Let's Encrypt client: ``` sudo apt update sudo apt install -y certbot python3-certbot-nginx ``` ### Obtain an SSL Certificate Make sure your domain's DNS A record points to your server's IP address before running this command: ``` sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com ``` Certbot will: 1. Ask for your email (for renewal notifications) 2. Ask you to agree to the terms of service 3. Ask if you want to redirect HTTP to HTTPS (choose Yes) 4. Automatically configure Nginx for SSL After completion, your Nginx configuration will be updated with SSL settings, and your site will be accessible via HTTPS. ### Verify Auto-Renewal Let's Encrypt certificates expire after 90 days. Certbot sets up automatic renewal, but let's verify it works: ``` # Test the renewal process (dry run) sudo certbot renew --dry-run # Check the renewal timer sudo systemctl status certbot.timer ``` If the dry run succeeds, your certificates will renew automatically. ## Step 8: Configure the UFW Firewall A firewall controls which network traffic can reach your server. UFW (Uncomplicated Firewall) is Ubuntu's default firewall tool and is easy to configure. ### Set Up UFW ``` # Allow SSH (important - don't lock yourself out!) sudo ufw allow OpenSSH # Allow HTTP and HTTPS traffic sudo ufw allow 'Nginx Full' # Enable the firewall sudo ufw enable # Check the status sudo ufw status ``` You should see output like: ``` Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Nginx Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Nginx Full (v6) ALLOW Anywhere (v6) ``` ### Important Notes on Ports Notice that we did **not** open port 3000 (where Node.js runs). This is intentional — your app is only accessible through Nginx, which adds a layer of security and allows for proper SSL termination. If you need to access other services (databases, Redis, etc.), either: - Keep them listening on localhost only (e.g., `127.0.0.1:5432` for PostgreSQL) - Whitelist specific IP addresses with `sudo ufw allow from YOUR_IP to any port 5432` ## Your Node.js App is Now Deployed Congratulations! You've successfully deployed a Node.js application to a VPS with a production-ready setup. Here's what you now have: - Node.js running via nvm (easy version management) - PM2 managing your process (auto-restart, clustering, logs) - Nginx as a reverse proxy (efficient routing, SSL termination) - Free SSL certificate from Let's Encrypt (auto-renewing) - UFW firewall (only necessary ports open) ### Updating Your Application When you push changes to your repository, here's how to deploy them: ``` # SSH into your server ssh deploy@your-server-ip # Navigate to your app cd ~/my-node-app # Pull the latest changes git pull origin main # Install any new dependencies npm ci --production # Build if needed npm run build # Restart PM2 pm2 restart my-node-app # Or reload for zero-downtime (if using cluster mode) pm2 reload my-node-app ``` You can automate this with a simple shell script or set up CI/CD with GitHub Actions. ## The Easy Way: Deploy with Server Compass in 3 Minutes The manual process we just covered works, but it's a lot of steps. Every deployment requires SSH access, remembering commands, and hoping nothing breaks. For ongoing projects, this adds up to hours of time every month. [Server Compass](/) automates everything you just learned — and more — through a visual desktop app. No terminal commands, no config files to edit, no certificates to manage manually. ![Server Compass auto-detecting Node.js framework and generating deployment configuration](/app-screenshots/feature-framework-detect.jpg) ### What Server Compass Automates - **Framework detection** — Automatically detects Express, Fastify, NestJS, Next.js, and 16+ other frameworks - **One-click Node.js templates** — Deploy pre-configured [Node.js stacks](/install/nodejs) with databases and caching - **GitHub integration** — Connect your repo and deploy any branch with one click - **Automatic SSL** — Let's Encrypt certificates provisioned and renewed automatically - **Nginx configuration** — Generated and optimized for your app, no manual editing - **PM2 setup** — Process management configured automatically with clustering - **Environment variables** — Secure [.env vault](/features/env-vault) with AES-256 encryption - **Zero-downtime deployments** — Blue-green deployment so your users never see downtime ### Deploy Your Node.js App in 3 Minutes 1. **Download Server Compass** from [servercompass.app](/) (Mac, Windows, Linux) 2. **Add your VPS** — Enter your server IP and SSH credentials. Server Compass handles the rest. 3. **Connect your GitHub repo** — Authorize GitHub and select your Node.js project. 4. **Click Deploy** — Server Compass detects your framework, builds your app, configures PM2 and Nginx, sets up SSL, and deploys. That's it. No SSH sessions, no command memorization, no config file editing. Every subsequent deployment is a single click. Looking for an alternative to expensive PaaS platforms? [See how Server Compass compares to Vercel](/vercel-alternative) for Node.js deployments. #### Ready to simplify your deployments? Server Compass is a one-time purchase ($29) with no monthly fees. Deploy unlimited Node.js apps to unlimited servers. [Try Server Compass Free](/) ## Troubleshooting FAQ ### My app shows 502 Bad Gateway. What's wrong? A 502 error means Nginx can't reach your Node.js app. Check these things: 1. **Is your app running?** Run `pm2 list` to see if it's online. 2. **Is it listening on the right port?** Your Nginx config says `proxy_pass http://127.0.0.1:3000` — make sure your app is on port 3000. 3. **Check the logs** with `pm2 logs my-node-app` for any crash messages. 4. **Check Nginx error logs** with `sudo tail -f /var/log/nginx/error.log`. ### npm install fails with permission errors This usually happens if you installed nvm as root but are running as a different user. Solutions: ``` # Make sure nvm is installed for your user curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash source ~/.bashrc nvm install --lts # Or fix permissions on node_modules sudo chown -R $(whoami) ~/my-node-app/node_modules ``` ### My app doesn't start after server reboot Make sure you ran the PM2 startup configuration: ``` # Generate startup script pm2 startup # Copy and run the command PM2 outputs # Save your process list pm2 save ``` ### SSL certificate isn't working Common causes: - **DNS not propagated** — Make sure your domain's A record points to your server IP. Use `dig yourdomain.com` to check. - **Port 80 blocked** — Let's Encrypt needs port 80 for verification. Make sure `sudo ufw allow 'Nginx Full'` was run. - **Rate limited** — Let's Encrypt limits certificate requests. Wait an hour and try again. ``` # Check Certbot logs sudo cat /var/log/letsencrypt/letsencrypt.log # Try again with verbose output sudo certbot --nginx -d yourdomain.com -v ``` ### How do I view my application logs? PM2 stores logs automatically: ``` # View real-time logs pm2 logs my-node-app # View last 100 lines pm2 logs my-node-app --lines 100 # View error logs only pm2 logs my-node-app --err # Clear logs pm2 flush ``` ### How do I set environment variables? There are several ways: ``` # Option 1: Create a .env file cat > .env << 'EOF' NODE_ENV=production DATABASE_URL=postgresql://user:pass@localhost:5432/mydb API_KEY=your-secret-key EOF # Then use dotenv in your app or PM2 ecosystem file # Option 2: Set in PM2 ecosystem file module.exports = { apps: [{ name: 'my-node-app', script: 'index.js', env: { NODE_ENV: 'production', DATABASE_URL: 'postgresql://...', } }] } # Option 3: Set inline when starting PORT=3000 NODE_ENV=production pm2 start index.js ``` ### Can I run multiple Node.js apps on one VPS? Absolutely. Just use different ports for each app: ``` # Start apps on different ports pm2 start app1/index.js --name "app1" -- --port 3001 pm2 start app2/index.js --name "app2" -- --port 3002 # Create separate Nginx configs for each domain/subdomain # pointing to the appropriate port ``` A single $5 VPS can easily run 5-10 lightweight Node.js applications. ## Next Steps Now that your Node.js app is deployed, consider these improvements: - **Set up CI/CD** — Automate deployments with GitHub Actions so pushing to main deploys automatically - **Add monitoring** — Deploy [Uptime Kuma](/templates/uptime-kuma) to monitor your app's availability - **Configure backups** — Set up automated backups of your database and application data - **Add a database** — Deploy [PostgreSQL](/templates/postgresql) or [MongoDB](/templates/mongodb) alongside your app - **Implement caching** — Add [Redis](/templates/redis) for session storage and caching With the foundation you've built, your VPS can grow into a complete production environment that rivals expensive PaaS platforms — at a fraction of the cost. Happy deploying! --- **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. 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. --- ## Stop Paying Netlify. Run Your Own Stack for $5/mo Source: https://servercompass.app/blog/netlify-pricing-vs-self-hosting-cost-comparison Published: 2026-03-06 Tags: netlify-alternative, pricing, self-hosted, deployment, comparisons Netlify Pro costs $19/member/mo and Business is $99/member. A team of 5 pays $95-495/mo. We show how to run unlimited sites on a $5 VPS with Server Compass. TL;DR Netlify Pro costs **$19/member/mo** — a team of 5 pays $95+/mo before overages. Server Compass lets you run unlimited sites on a **$5 VPS** with a one-time $29 payment — no per-seat fees, no build limits. [Try Server Compass free →](/) Netlify charges **per team member** — $19/seat on Pro, $99/seat on Business. Add a fifth developer and you're paying $95–$495/mo before bandwidth overages, build minutes, and function invocations pile on. The more your team grows, the worse the math gets. Here's the part Netlify's pricing page glosses over: the hidden costs that turn a “free tier” into a $200+/mo bill, and exactly when self-hosting on a VPS starts saving you real money. We run the numbers below so you don't have to. Pricing verified March 2026. Check Netlify's pricing page for the latest rates. ## Netlify Pricing Breakdown: What You Actually Pay Netlify offers four pricing tiers, but the jump from free to paid is where most developers feel the pinch. Let's examine each tier in detail. ### Free Tier (Starter) Netlify's free tier is genuinely generous for hobby projects and personal sites: - **Build minutes:** 300 minutes/month - **Bandwidth:** 100 GB/month - **Concurrent builds:** 1 - **Team members:** 1 - **Form submissions:** 100/month - **Serverless functions:** 125,000 requests/month, 100 hours execution - **Edge functions:** 3 million invocations/month **The catch:** One team member only. The moment you need to add a colleague, contractor, or co-founder, you're forced onto a paid plan. There's no middle ground—no $5/month option for small teams. ### Pro Tier ($19/member/month) The Pro tier is where Netlify's per-seat model starts to hurt: - **Build minutes:** 25,000 minutes/month (shared across team) - **Bandwidth:** 1 TB/month (shared) - **Concurrent builds:** 3 - **Team members:** Unlimited (but $19 each) - **Form submissions:** 1,000/month - **Serverless functions:** Included (up to limits) - **Analytics:** Basic site analytics included - **Support:** Email support **Real-world cost calculation:** - Solo developer: $19/month - Team of 3: $57/month - Team of 5: $95/month - Team of 10: $190/month And that's just the base cost. Exceed your bandwidth or build minutes, and overages kick in. ### Business Tier ($99/member/month) For teams requiring advanced features, the Business tier multiplies the per-seat pain: - **Everything in Pro, plus:** - **Build minutes:** 25,000 minutes/month - **Bandwidth:** 1.5 TB/month - **Concurrent builds:** 5 - **SAML SSO:** Single sign-on for enterprise auth - **Role-based access:** Granular permissions - **Audit logs:** Compliance-ready logging - **99.99% SLA:** Uptime guarantee - **Priority support:** Faster response times **Real-world cost calculation:** - Solo developer: $99/month - Team of 3: $297/month - Team of 5: $495/month - Team of 10: $990/month At $495/month for a five-person team, you're paying nearly $6,000/year—enough to run enterprise-grade infrastructure with money left over. ### Enterprise Tier (Custom Pricing) Enterprise pricing is negotiated, but expect to pay significantly more than Business rates. Features include dedicated support, custom SLAs, higher limits, and enterprise integrations. Most enterprises report paying $1,000-5,000+/month depending on team size and requirements. ## The Hidden Costs That Inflate Your Netlify Bill Base pricing tells only part of the story. These additional charges catch many teams off guard. ### Build Minutes Overages Build minutes are consumed every time Netlify builds your site. Modern frameworks like Next.js, Nuxt, and Astro can consume 2-10 minutes per build depending on project size. - **Pro tier includes:** 25,000 minutes/month - **Overage rate:** $7 per 500 minutes - **That's:** $0.014 per minute ($0.84/hour) **Example scenario:** Your Next.js app takes 5 minutes to build. With 3 team members pushing 10 times/day each, that's 150 builds/day or 4,500 builds/month. At 5 minutes each: 22,500 minutes—you're close to the limit. Add preview deploys for pull requests, and you're easily over. **Potential overage:** 10,000 extra minutes = $140/month ### Bandwidth Overages Bandwidth limits bite hardest during traffic spikes—exactly when you should be celebrating success, not worrying about bills. - **Pro tier includes:** 1 TB/month - **Overage rate:** $55 per 100 GB - **That's:** $0.55 per GB **Comparison:** Major VPS providers charge $0.01-0.02 per GB for bandwidth, or include 1-10 TB free with servers. Netlify's bandwidth is **27-55x more expensive** than VPS bandwidth. **Example scenario:** Your site goes viral, serving 2 TB in a month. That 1 TB overage costs you **$550**—on top of your base subscription. ### Forms Pricing Netlify Forms are convenient but expensive at scale: - **Free tier:** 100 submissions/month - **Pro tier:** 1,000 submissions/month - **Additional submissions:** $19 per 500 submissions A contact form on a popular site receiving 5,000 submissions/month would cost an extra $152/month in form fees alone. Self-hosted alternatives like Formspree or a simple API endpoint on your VPS cost a fraction of this. ### Serverless Functions Pricing Netlify Functions have hidden limits that affect real applications: - **Level 0 (Free):** 125,000 invocations, 100 hours runtime - **Level 1:** 2 million invocations, 1,000 hours—$25/month - **Level 2:** 5 million invocations, 2,500 hours—$75/month - **Level 3:** 10 million invocations, 5,000 hours—$150/month **The runtime trap:** If your functions handle database queries, API calls, or any I/O operations, the 100-hour free tier runtime disappears fast. A function averaging 500ms execution time burns through 100 hours in just 720,000 invocations—well under the 125,000 invocation limit. ### Large Media and Storage Need to host large files or use Netlify Large Media? - **Large Media storage:** $0.03 per GB/month - **Large Media bandwidth:** $0.20 per GB For media-heavy sites, these costs compound quickly. A portfolio site with 50 GB of images serving 500 GB/month would add $101.50/month to your bill. ## Self-Hosting Cost Reality: What a VPS Actually Costs Self-hosting sounds intimidating until you see the numbers. Modern VPS providers offer incredible value, and tools like [Server Compass](/) eliminate the DevOps complexity. ### VPS Pricing Comparison (2026) Here's what you get from major VPS providers: #### Entry-Level ($5-12/month) - **Hetzner CX22:** $4.85/month—2 vCPU, 4 GB RAM, 40 GB SSD, 20 TB bandwidth - **DigitalOcean Basic:** $12/month—1 vCPU, 2 GB RAM, 50 GB SSD, 2 TB bandwidth - **Vultr Cloud Compute:** $12/month—1 vCPU, 2 GB RAM, 55 GB SSD, 2 TB bandwidth - **Linode Shared:** $12/month—1 vCPU, 2 GB RAM, 50 GB SSD, 2 TB bandwidth #### Mid-Range ($24-48/month) - **Hetzner CX32:** $9.70/month—4 vCPU, 8 GB RAM, 80 GB SSD, 20 TB bandwidth - **DigitalOcean Premium:** $24/month—2 vCPU, 4 GB RAM, 80 GB SSD, 4 TB bandwidth - **Vultr High Performance:** $24/month—2 vCPU, 4 GB RAM, 100 GB NVMe, 3 TB bandwidth #### Production-Ready ($48-96/month) - **Hetzner CX42:** $19.40/month—8 vCPU, 16 GB RAM, 160 GB SSD, 20 TB bandwidth - **DigitalOcean Premium:** $48/month—4 vCPU, 8 GB RAM, 160 GB SSD, 5 TB bandwidth - **Vultr Bare Metal:** $96/month—dedicated E-2286G, 32 GB RAM, 2x 256 GB SSD ### What You Get with a VPS For that fixed monthly cost, you receive: - **Unlimited builds:** Build as often as you want - **Generous bandwidth:** 2-20 TB included (vs 1 TB on Netlify Pro) - **Unlimited team members:** No per-seat charges - **Unlimited sites:** Deploy as many projects as RAM allows - **Full server access:** Install any software, run any process - **Database hosting:** Run PostgreSQL, MySQL, Redis on the same server - **No function limits:** Your app runs continuously, not per-invocation - **Predictable billing:** Same cost every month, no surprises ## Cost Comparison: Netlify vs Self-Hosting Let's compare realistic scenarios across different team sizes. ### Solo Developer Cost Factor Netlify Pro Self-Hosted VPS Base cost $19/month $12/month (DigitalOcean) Typical overages $20-50/month $0 Database $15+ (external service) $0 (included) **Monthly total** **$54-84** **$12** **Annual total** **$648-1,008** **$144** **Annual savings** — **$504-864** ### Team of 3 Cost Factor Netlify Pro Self-Hosted VPS Base cost $57/month (3 x $19) $24/month (4 GB VPS) Build minute overages $28-70/month $0 Bandwidth overages $55-110/month $0 Database $25+ (managed DB) $0 (included) **Monthly total** **$165-262** **$24** **Annual total** **$1,980-3,144** **$288** **Annual savings** — **$1,692-2,856** ### Team of 5 Cost Factor Netlify Pro Netlify Business Self-Hosted VPS Base cost $95/month $495/month $48/month (8 GB VPS) Build overages $70-140/month $70-140/month $0 Bandwidth overages $110-220/month $55-165/month $0 Functions tier $25-75/month $25-75/month $0 Database $50+/month $50+/month $0 (included) **Monthly total** **$350-530** **$695-925** **$48** **Annual total** **$4,200-6,360** **$8,340-11,100** **$576** **Annual savings** — — **$3,624-10,524** For a team of five, self-hosting saves between **$3,624 and $10,524 annually** —enough to fund additional development time, better tooling, or simply improve your bottom line. ## When Netlify Makes Sense Despite the costs, Netlify remains an excellent choice in specific scenarios: ### Hobby Projects and Portfolios If you're a solo developer with a personal site, portfolio, or side project that stays within free tier limits, Netlify is hard to beat. Zero cost, zero maintenance, zero thinking about servers. ### Zero DevOps Tolerance Some teams genuinely have no interest or capacity for any infrastructure work. If the thought of managing a server causes anxiety and you're willing to pay the premium, Netlify's managed approach removes that burden entirely. ### Global Edge Requirements Netlify's edge network provides genuine value for globally distributed audiences. Their CDN and edge functions run in 100+ locations worldwide. Replicating this with self-hosting requires multi-region infrastructure that adds complexity and cost. ### Enterprise Compliance Needs If you need SOC 2 Type II compliance, GDPR data processing agreements, or enterprise SLAs with legal backing, Netlify's Enterprise tier provides these out of the box. Building equivalent compliance on self-hosted infrastructure requires significant investment. ### Rapid Prototyping Phase During early product development when you're iterating rapidly and team size is uncertain, Netlify's flexibility can be worth the premium. Migrate to self-hosting once your architecture stabilizes. ## When Self-Hosting Wins For most growing teams, self-hosting delivers compelling advantages: ### Growing Teams (2+ Members) The moment you add a second team member, Netlify's per-seat pricing kicks in. Self-hosting has zero marginal cost per developer—add ten team members tomorrow and your VPS bill stays the same. ### Traffic Growth or Unpredictability If your site might go viral, get featured on Hacker News, or experience seasonal traffic spikes, self-hosting protects you from bandwidth overage shock. A VPS with 20 TB included bandwidth handles traffic spikes without billing surprises. ### Multiple Projects or Clients Agencies and developers managing multiple sites see massive savings with self-hosting. Run 20 client sites on one $48/month VPS instead of paying $380+/month across separate Netlify projects. ### Full-Stack Applications Need a database? Background jobs? WebSocket connections? Cron tasks? Self-hosting gives you a complete environment where you can run any service without per-feature charges. ### Cost Predictability Requirements Startups and bootstrapped businesses need predictable expenses. A fixed $24-48/month VPS bill is infinitely easier to budget than variable Netlify charges that fluctuate with traffic and usage. ### Data Sovereignty For applications requiring data to stay in specific geographic regions or on infrastructure you control, self-hosting on a VPS in your chosen location provides complete data sovereignty. ## Migration Considerations: Netlify to Self-Hosted If you've decided to migrate, here's what to expect: ### Migration Complexity by Stack #### Static Sites (Easy) Gatsby, Hugo, Jekyll, and static HTML sites migrate trivially. Build locally or via CI, deploy the output folder. Server Compass auto-detects these frameworks and configures builds automatically. #### Next.js / Nuxt / SvelteKit (Moderate) These frameworks work perfectly on self-hosted infrastructure. The main consideration is switching from serverless to Node.js server mode. Server Compass provides optimized Docker configurations for each framework with zero configuration required. #### Netlify Functions (Moderate) Netlify Functions need conversion to Express/Fastify endpoints or kept as serverless functions using alternatives like AWS Lambda. For most applications, converting to a standard Node.js API is simpler and more performant. #### Netlify Forms (Easy) Replace with self-hosted form handlers, Formspree, or simple API endpoints. Most migrations take under an hour per form. #### Netlify Identity (Moderate) Switch to Auth.js (NextAuth), Clerk, or self-hosted solutions like Keycloak. This requires user migration but often provides more flexibility. ### Typical Migration Timeline - **Simple static site:** 1-2 hours - **Next.js with API routes:** 2-4 hours - **Full stack with Forms + Functions:** 4-8 hours - **Complex app with Identity:** 1-2 days For detailed migration steps, see our [Netlify Alternative guide](/netlify-alternative) and [Netlify comparison page](/compare/netlify). ### Tools That Make Migration Painless [Server Compass](/) eliminates the DevOps complexity of self-hosting: - **Framework detection:** Automatically identifies Next.js, Nuxt, Astro, and 16+ other frameworks - **Docker generation:** Creates optimized Dockerfiles without manual configuration - **Git-based deployments:** Push to deploy, just like Netlify - **Automatic HTTPS:** Let's Encrypt certificates configured automatically - **Environment management:** Secure env var handling with encryption - **Zero-downtime deploys:** Blue-green deployments built in - **Database templates:** Deploy PostgreSQL, MySQL, Redis with one click ## Frequently Asked Questions ### Are there hidden costs with VPS hosting? VPS pricing is straightforward. You pay the advertised monthly rate plus any bandwidth overages (which are rare given generous included bandwidth). Some providers charge for backups ($1-5/month) or additional IPs, but these are optional and clearly priced. There are no per-seat charges, per-build charges, or per-function charges. ### Do I need DevOps knowledge to self-host? Traditional self-hosting required significant Linux and Docker expertise. Modern tools like Server Compass abstract this complexity entirely. If you can use Netlify's dashboard, you can use Server Compass. The learning curve is minimal—most developers are productive within an hour. ### Is self-hosting as reliable as Netlify? Major VPS providers (DigitalOcean, Hetzner, Vultr, Linode) offer 99.99% uptime SLAs. With proper configuration—which Server Compass handles automatically—self-hosted sites achieve equivalent reliability. For critical applications, you can implement multi-server redundancy at a fraction of Netlify Business pricing. ### How do I handle SSL certificates? Server Compass configures Let's Encrypt certificates automatically with auto-renewal. You get the same HTTPS experience as Netlify with zero manual configuration. ### Can I still have preview deployments for PRs? Yes. Server Compass supports preview deployments triggered by pull requests. Each PR gets its own preview URL, just like Netlify's deploy previews. ### What about CDN and global performance? For most applications, a well-configured VPS with proper caching delivers excellent performance. If you need global edge distribution, pair your VPS with Cloudflare (free tier) or BunnyCDN ($0.01/GB) for CDN capabilities at a fraction of the cost. ### How do I scale if my site grows? VPS scaling is simple: upgrade to a larger server (usually takes minutes with no downtime) or add additional servers. Unlike per-seat pricing, scaling is based on actual resource needs rather than team size. ### What about support? VPS providers offer 24/7 support for infrastructure issues. For application-level support, Server Compass provides documentation, community forums, and email support. The self-hosted community is large and active—most questions have existing answers. ## Conclusion: Do the Math for Your Situation Netlify built an excellent developer experience, but their per-seat pricing model creates painful economics for growing teams. The math is simple: - **Solo developer on free tier:** Stay on Netlify - **Solo developer exceeding limits:** Consider self-hosting ($144/year vs $648+/year) - **Team of 3+:** Self-hosting saves $1,500-3,000+ annually - **Team of 5+:** Self-hosting saves $3,500-10,000+ annually The decision comes down to whether you value convenience over cost savings and control. For hobby projects, Netlify's free tier is perfect. For anything beyond that, the economics favor self-hosting—especially with modern tools that eliminate the traditional DevOps burden. Ready to take control of your infrastructure and stop paying per-seat premiums? [Try Server Compass](/) and see how much you'll save. Your annual budget will thank you. --- **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 Costs $20+/mo. This Tool Costs $29 Once Source: https://servercompass.app/blog/railway-pricing-what-youll-actually-pay Published: 2026-03-06 Tags: railway, pricing, paas, vps-deploy, self-hosted Railway's usage-based billing adds up fast — most real apps cost $20-50/mo. We break down every charge and show how Server Compass lets you self-host the same stack on a $5 VPS. TL;DR Most real apps on Railway cost **$20–50+/mo** with usage-based billing. Server Compass lets you self-host the same stack on a **$5 VPS** for a one-time $29 payment — predictable costs, no surprises. [Try Server Compass free →](/) Railway promises “pay for what you use” — but developers keep getting surprised by bills that are 2–5x what they expected. A Node.js app with a PostgreSQL database? That's $15–30/mo. Add Redis and a background worker? You're looking at $40–60/mo. The usage-based model makes it nearly impossible to predict your actual costs. But here's what Railway's pricing calculator won't show you: how CPU and memory charges compound under real traffic, why egress fees catch teams off guard, and at what point a simple $5 VPS becomes the obvious alternative. We break down every charge below. Pricing verified March 2026. Railway uses dynamic usage-based pricing — your costs will vary. ## Railway Pricing Model Explained Unlike platforms with fixed monthly plans, Railway charges based on actual resource consumption. This means your bill varies month to month depending on how much CPU, memory, network, and storage your applications use. Let's break down each component. ### The Credit-Based System Railway operates on a credit system where $1 equals 1 credit. Your account accumulates charges throughout the month based on resource usage, and you're billed at the end of the billing cycle. This approach means you never pay upfront for resources you might not use — but it also means unpredictable bills if you're not careful. ### Free Tier ($5 Credit) Railway offers a trial tier that includes $5 of free usage. This sounds generous, but let's put it in perspective: - **Execution hours**: Approximately 500 hours of a basic service (assuming minimal CPU and ~256MB RAM) - **What that means**: A single always-on service runs 720+ hours per month, so you'll exceed the free tier quickly - **Verification required**: You need to verify your account (credit card or GitHub account with history) to access the trial - **No databases on trial**: The free tier has limited database provisioning The trial is best for testing Railway or running occasional one-off tasks — not for hosting production applications. ### Hobby Plan ($5/month) The Hobby plan costs $5 per month and includes: - $5 of resource usage included - Access to all Railway features - Unlimited services - Community support **Important**: The $5 is a credit toward usage, not a flat fee. If you use more than $5 worth of resources, you pay the difference. If you use less, you don't get a refund — it's use-it-or-lose-it. ### Pro Plan ($20/month per seat) The Pro plan costs $20 per month per team member and includes: - $20 of resource usage included per seat - Higher resource limits - Team collaboration features - Priority support - Advanced metrics and observability Again, the $20 is credit toward usage. A team of 3 on the Pro plan pays $60/month minimum, with $60 in usage credit. Exceed that, and you pay overage. ## What Costs Money on Railway Understanding Railway's pricing requires knowing exactly what gets metered. Here's the complete breakdown of billable resources as of 2026. ### CPU Usage Resource Price Calculation vCPU $0.000463 per vCPU minute ~$0.028/hour, ~$20/month for 1 vCPU 24/7 CPU is charged per vCPU-minute. If your application uses 0.5 vCPU on average, you pay half the rate. The challenge is that CPU usage can spike unpredictably — a traffic surge or a heavy background job can suddenly increase your bill. **Example calculation**: An app using 0.25 vCPU continuously for a month: ``` 0.25 vCPU × 43,200 minutes × $0.000463 = $5.00/month ``` ### Memory Usage Resource Price Calculation RAM $0.000231 per GB minute ~$0.014/hour per GB, ~$10/month for 1GB 24/7 Memory is charged per GB-minute. Unlike CPU which can fluctuate, memory usage tends to be more stable — but also more predictable to calculate. **Example calculation**: A Node.js app using 512MB RAM continuously: ``` 0.5 GB × 43,200 minutes × $0.000231 = $4.99/month ``` ### Network Egress Resource Price Notes Outbound traffic $0.10 per GB First 100GB included on Pro plan Network egress — data leaving Railway to the internet — costs $0.10 per GB. This includes: - API responses sent to clients - Images and files served by your app - Database query results (if accessed externally) - Webhook payloads Internal traffic between Railway services is free, which is a significant advantage for microservice architectures. **Example**: A medium-traffic API serving 50GB of responses per month: ``` 50 GB × $0.10 = $5.00/month ``` ### Persistent Storage Resource Price Notes Volume storage $0.25 per GB month SSD-backed persistent volumes Persistent volumes for databases and file storage cost $0.25 per GB per month. This is relatively affordable, but it adds up for data-heavy applications. **Example**: A PostgreSQL database with 20GB of data: ``` 20 GB × $0.25 = $5.00/month ``` ## Real-World Cost Examples Now let's calculate what you'll actually pay for common Railway deployments. These examples use realistic resource consumption based on typical applications. ### Example 1: Simple Node.js/Express API A basic Express API handling 10,000 requests per day with low complexity: Resource Usage Monthly Cost CPU 0.1 vCPU average $2.00 Memory 256MB constant $2.49 Network 5GB egress $0.50 **Total** **$4.99/month** A simple API fits within the Hobby plan's $5 credit. But this is a minimal app with low traffic. Scale it up, and costs rise quickly. ### Example 2: PostgreSQL Database A managed PostgreSQL database for a typical SaaS application: Resource Usage Monthly Cost CPU 0.25 vCPU average $5.00 Memory 1GB constant $9.98 Storage 10GB $2.50 **Total** **$17.48/month** A PostgreSQL database alone costs nearly $18/month — exceeding the Hobby plan's included credit by almost 3.5x. This is where Railway's pricing becomes less competitive compared to self-hosted alternatives. ### Example 3: Full-Stack App with Database A Next.js application with PostgreSQL and Redis — a common production stack: Service CPU Memory Storage Network Cost Next.js App 0.25 vCPU 512MB \- 20GB $11.99 PostgreSQL 0.25 vCPU 1GB 15GB \- $18.73 Redis 0.1 vCPU 256MB 1GB \- $4.74 **Total** **$35.46/month** A typical full-stack application costs around $35-40/month on Railway. Add more services, handle more traffic, or store more data, and you're quickly looking at $50-100+/month. ### Example 4: High-Traffic Production App A SaaS application with 100,000 daily active users: Service Resources Monthly Cost API Server (2 instances) 0.5 vCPU, 1GB RAM each $39.92 PostgreSQL 0.5 vCPU, 2GB RAM, 50GB storage $42.46 Redis 0.25 vCPU, 512MB RAM $9.99 Background Worker 0.5 vCPU, 1GB RAM $19.96 Network Egress 200GB $20.00 **Total** **$132.33/month** At scale, Railway costs can exceed $130/month — and this is still a modest production workload. High-growth startups often see Railway bills reach $300-500+/month. ## Railway vs VPS Cost Comparison How does Railway compare to running the same workloads on a VPS? Let's compare side-by-side for the full-stack example above. Platform Configuration Monthly Cost **Railway** Next.js + PostgreSQL + Redis $35-40 **Hetzner VPS** CX21 (2 vCPU, 4GB RAM, 40GB SSD) $4.85 **DigitalOcean** Basic Droplet (2 vCPU, 4GB RAM, 80GB SSD) $24.00 **Vultr** Cloud Compute (2 vCPU, 4GB RAM, 80GB SSD) $24.00 A single VPS can run all three services (Next.js, PostgreSQL, Redis) with room to spare. The cost difference is dramatic: - **Railway**: $35-40/month (usage-based, can fluctuate) - **Hetzner VPS**: $4.85/month (fixed, predictable) - **Annual savings**: **$360-420** by self-hosting For the high-traffic example, the difference is even more stark: - **Railway**: $132/month - **Hetzner VPS (CPX31)**: $14.76/month (4 vCPU, 8GB RAM, 160GB) - **Annual savings**: **$1,406** by self-hosting ## When Railway Makes Sense Despite the cost difference, Railway can be the right choice in certain scenarios: ### Railway is a Good Fit When: - **You're prototyping or building MVPs** — The speed of deployment justifies the cost for short-term projects - **You have variable workloads** — If your app runs intensively for a few hours, then sits idle, usage-based pricing can work in your favor - **You need instant scaling** — Railway handles scaling automatically; no manual intervention needed - **Your team lacks DevOps experience** — Zero infrastructure management means developers focus purely on code - **You're spending under $20/month** — For very small apps, the convenience may be worth the premium ## When to Switch to VPS Self-hosting becomes the smarter choice as your application grows. Consider switching when: ### A VPS is Better When: - **Your Railway bill exceeds $30-50/month** — At this point, a VPS provides better value - **You need predictable costs** — VPS pricing is fixed; no surprise bills from traffic spikes - **You're running databases** — Managed databases on Railway are expensive; self-hosted databases cost only the disk space - **You need more control** — Custom configurations, specific software versions, or specialized setups - **You're running multiple projects** — A single VPS can host 5-10 applications for the price of one on Railway - **You want to own your infrastructure** — No vendor lock-in, full data ownership For a deeper comparison, see our [Railway vs Server Compass comparison](/compare/railway). ## Alternative: Predictable Costs with Server Compass If Railway's usage-based pricing doesn't fit your budget, self-hosting on your own VPS offers a compelling alternative. But you don't have to sacrifice developer experience to get predictable costs. [Server Compass](/) gives you the deployment simplicity of Railway while running on your own VPS: - **One-click deployments** — Connect your GitHub repo and deploy with a click, just like Railway - **100+ templates** — Deploy PostgreSQL, Redis, MongoDB, and more from the [template library](/templates) - **Automatic SSL** — Let's Encrypt certificates provisioned automatically - **GitHub Actions CI/CD** — Zero-downtime deployments via [automated pipelines](/features/github-actions) - **Framework detection** — Auto-detect 16+ frameworks including Node.js, Python, Go, and more - **Fixed pricing** — $29 one-time license + your VPS cost (starting at $5/month) ### Cost Comparison Summary Stack Railway Server Compass + Hetzner Annual Savings Simple API $5-10/month $4.85/month $0-60 Full-stack + DB $35-40/month $4.85/month $360-420 Production SaaS $100-150/month $10-20/month $960-1,560 See our complete [Railway alternative guide](/railway-alternative) for more details on migrating from Railway to self-hosted infrastructure. ## Hidden Costs and Gotchas Before committing to Railway, be aware of these less-obvious cost factors: ### Build Minutes Railway charges for build time at the same rate as runtime. A complex build that takes 5-10 minutes can cost $0.50-1.00 per deployment. Deploy 10 times a day during active development, and that's an extra $150-300/month. ### Preview Environments Railway's preview deployments are convenient but cost real money. Each PR creates a new environment with its own resources. Active development with multiple PRs can significantly increase costs. ### Database Backups Point-in-time recovery and backups consume storage, which is charged at $0.25/GB/month. A database with 30 days of backups can cost 2-3x the base storage cost. ### Idle Services Unlike some platforms, Railway charges for idle services. An always-on service that handles minimal traffic still incurs CPU and memory charges 24/7. ## Frequently Asked Questions ### Is Railway really free? Railway offers a trial tier with $5 of free usage, but this is very limited. A single always-on service with a database will exceed this within the first week. The trial is best for testing, not production use. ### Is Railway cheaper than Vercel? It depends on your workload. Railway can be cheaper for applications that need databases, WebSockets, or background workers — things Vercel doesn't handle well. But for simple frontend deployments, Vercel's free tier is more generous. ### How can I predict my Railway costs? Railway provides a usage dashboard showing real-time costs. For estimates, use this formula: ``` Monthly Cost = (vCPU hours × $0.028) + (GB-hours RAM × $0.014) + (GB egress × $0.10) + (GB storage × $0.25) ``` Monitor your first week of usage, then multiply by 4 for a monthly estimate. ### Can I set cost limits on Railway? Railway allows you to set usage limits and alerts, but these are soft limits — your services may be stopped if you exceed them, potentially causing downtime. There's no hard spending cap that keeps services running while preventing overages. ### Why are databases so expensive on Railway? Railway databases run as full services with dedicated CPU, memory, and storage — all billed separately. A modest PostgreSQL instance easily costs $15-20/month, whereas the same database on a VPS uses existing resources at no additional cost. ### How do I migrate from Railway to a VPS? Migration involves: 1. Setting up a VPS with Docker 2. Exporting your database from Railway 3. Deploying your application containers to the VPS 4. Updating DNS to point to your VPS Tools like [Server Compass](/) simplify this process with one-click database deployments and GitHub integration. See our [Railway alternative guide](/railway-alternative) for detailed migration steps. ### Is Railway worth it? Railway is worth it for small projects, prototypes, and teams that prioritize developer experience over cost optimization. Once your bill exceeds $30-50/month consistently, self-hosting becomes more economical while still providing a great developer experience with the right tools. ## Conclusion Railway's usage-based pricing offers flexibility but can lead to unpredictable and often higher costs than alternatives. For simple applications under $20/month, Railway provides excellent value through its developer experience. But as your application grows, the cost-per-resource quickly exceeds what you'd pay for equivalent VPS infrastructure. The key takeaways for understanding **Railway pricing**: - CPU costs ~$20/month per full vCPU; memory costs ~$10/month per GB - Databases are expensive: expect $15-25/month minimum for PostgreSQL - Full-stack applications typically cost $35-50/month on Railway - The same workload costs $5-15/month on a self-managed VPS - Annual savings of $360-1,500+ are possible by self-hosting If you're looking for Railway's deployment simplicity without the usage-based pricing surprises, consider [Server Compass](/). Get one-click deployments, managed databases, and automatic SSL — all on your own VPS for a fixed monthly cost. **Related resources:** - [Railway Alternative: Self-Host with Server Compass](/railway-alternative) - [Railway vs Server Compass: Detailed Comparison](/compare/railway) - [Why Self-Hosting Is the Smartest Move for Developers](/blog/why-self-hosting-is-the-smartest-move-for-developers) - [Deploy PostgreSQL on Your VPS](/templates/postgresql) --- **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 Is Getting Expensive. Here's a $5/mo Alternative Source: https://servercompass.app/blog/render-pricing-is-it-worth-it Published: 2026-03-06 Tags: render-alternative, pricing, self-hosted, deployment Render's free tier is gone and paid plans start at $7/mo per service. We break down the real costs and show you how to run the same stack on a $5 VPS with Server Compass. TL;DR Render costs **$7–25+/mo per service** and the free tier is gone. Server Compass lets you self-host the same stack on a **$5 VPS** with a one-time $29 payment — no terminal needed. [Try Server Compass free →](/) If you're here, you're probably staring at a Render bill wondering how a “simple deployment platform” got this expensive. You're not alone — Render's free tier is effectively gone, and paid plans start at $7/mo *per service*. Run a web app, a database, and a worker? That's $21/mo minimum before you even think about scaling. But here's what Render's pricing page doesn't make obvious: the costs that quietly compound as your project grows. Below, we break down every tier, expose the charges that catch developers off guard, and show you exactly when it makes financial sense to move to a $5 VPS instead. Pricing verified March 2026. Costs change frequently — check Render's pricing page for the latest. ## Render Pricing Model Overview Render uses a **fixed monthly pricing** model for most services, which sets it apart from usage-based platforms like Railway or Vercel. This predictability is one of Render's biggest selling points — you know exactly what you'll pay each month without worrying about traffic spikes causing surprise bills. However, Render's pricing structure has several layers: - **Account-level plans**: Individual, Team, Organization, and Enterprise - **Service-level pricing**: Each web service, database, cron job, and background worker has its own monthly cost - **Resource tiers**: Within each service type, you choose CPU/RAM configurations - **Add-ons**: Persistent disks, additional bandwidth, and premium support carry extra fees Understanding how these layers interact is crucial to estimating your actual monthly spend on Render. ## Render Pricing Tiers ### Free Tier Limitations Render offers a free tier that's attractive for hobby projects and learning, but comes with significant limitations that make it unsuitable for anything beyond experimentation: Feature Free Tier Limit Impact Web Services 750 hours/month (shared) ~31 days if running one service continuously Spin Down After 15 minutes of inactivity 30-60 second cold starts for first request RAM 512 MB Tight for Node.js/Python apps with dependencies CPU 0.1 vCPU (shared) Noticeable slowdowns under any load Bandwidth 100 GB/month Sufficient for low-traffic sites Build Minutes 500 minutes/month ~16 builds for a typical Next.js app PostgreSQL 90 days only, then deleted Not viable for any persistent data Redis Not available Must pay for caching layer The most significant limitation is the **spin-down behavior**. Free tier services go to sleep after 15 minutes of inactivity, resulting in cold starts of 30-60 seconds when the next request arrives. This makes free tier unsuitable for production APIs, webhooks, or any service where response time matters. The 90-day PostgreSQL limit is another deal-breaker for real projects. Your database simply gets deleted after 90 days unless you upgrade to a paid plan. ### Individual Plan ($7+/month) The Individual plan removes free tier restrictions and gives you access to Render's full service catalog. However, you pay per service: - **No account fee**: You only pay for the services you deploy - **Web services start at $7/month**: For 512 MB RAM, 0.5 vCPU - **No spin-down**: Services stay running 24/7 - **Autoscaling available**: Pay for additional instances as needed - **Custom domains**: Included with automatic SSL For a solo developer running a single web service, $7/month is competitive. The challenge is that most real applications need more than one service. ### Team Plan ($19+/user/month) Teams need collaboration features, which come at a premium: - **$19/user/month**: Base cost for team collaboration - **Role-based access control**: Manage permissions across services - **Shared environments**: Preview environments and staging - **Priority support**: Faster response times - **Service costs are additional**: The $19/user is on top of infrastructure costs For a 5-person team, you're looking at $95/month just for the team plan — before any services are deployed. Add web services, databases, and background workers, and costs escalate quickly. ## Service-Specific Costs ### Web Services Web services are Render's core offering. Here's the 2026 pricing breakdown: Instance Type RAM CPU Monthly Cost Starter 512 MB 0.5 vCPU $7 Standard 2 GB 1 vCPU $25 Pro 4 GB 2 vCPU $85 Pro Plus 8 GB 4 vCPU $175 Pro Max 16 GB 8 vCPU $350 Pro Ultra 32 GB 16 vCPU $700 The $7 Starter tier works for simple apps, but most production workloads need at least the Standard tier at $25/month. The jump from Standard to Pro is steep — $60/month more for double the resources. **Autoscaling costs**: If you enable autoscaling, each additional instance costs the same as your base instance. Running 3 instances of a Standard service costs $75/month. ### Databases Render offers managed PostgreSQL and Redis. Database pricing is where costs can escalate significantly: #### PostgreSQL Pricing Plan RAM Storage Monthly Cost Starter 256 MB 1 GB $7 Basic 1 GB 16 GB $20 Standard 4 GB 96 GB $95 Pro 8 GB 256 GB $185 Pro Plus 16 GB 512 GB $395 The $7 Starter database has only 256 MB RAM and 1 GB storage — suitable for development but inadequate for production. The Basic tier at $20/month is the minimum viable option for real applications. **Important limitation**: Render PostgreSQL doesn't include point-in-time recovery on lower tiers. For proper backup protection, you need Standard ($95/month) or higher. #### Redis Pricing Plan Memory Monthly Cost Starter 25 MB $10 Basic 100 MB $25 Standard 1 GB $85 Pro 5 GB $185 Redis pricing is particularly steep. A 25 MB Starter instance costs $10/month — compare this to running Redis on a $5 VPS with gigabytes of available memory. ### Cron Jobs Render charges for cron jobs based on execution time and instance size: - **Minimum $1/month**: For jobs running a few minutes total - **Same instance pricing as web services**: A Pro instance running cron jobs costs $85/month equivalent - **Billed per second**: You pay only for actual execution time For simple scheduled tasks (daily cleanups, reports), cron jobs are affordable. But if you have multiple jobs or long-running processes, costs add up. ### Static Sites This is where Render shines for budget-conscious developers: - **Free**: Unlimited static sites - **100 GB bandwidth/month**: Per site on free tier - **Global CDN**: Included at no cost - **Custom domains**: With automatic SSL - **Build minutes count against total**: 500/month free, then $0.01/minute For static sites, Render is genuinely competitive with Netlify and Vercel. If you're only hosting static content, Render's free tier is excellent. ### Background Workers Background workers follow the same pricing as web services. A common pattern is running: - Web service (API): $25/month - Background worker (job processing): $25/month - Redis (job queue): $25/month That's $75/month just for a basic async job processing setup — before you add a database. ## Real Cost Examples Let's look at what real applications cost on Render: ### Simple SaaS App A typical small SaaS with moderate traffic: Service Tier Monthly Cost Next.js Frontend Standard (2 GB) $25 Node.js API Standard (2 GB) $25 PostgreSQL Basic (1 GB) $20 Redis Starter (25 MB) $10 **Total** **$80/month** ### Production App with Workers A production app with background job processing: Service Tier Monthly Cost Next.js App (2 instances) Standard $50 API Server (2 instances) Standard $50 Background Worker Standard $25 PostgreSQL Standard (4 GB) $95 Redis Basic (100 MB) $25 Cron Jobs Various $10 **Total** **$255/month** ### Team Production Setup A 4-person team with staging and production: Cost Item Monthly Cost Team Plan (4 users) $76 Production Environment (same as above) $255 Staging Environment (scaled down) $80 **Total** **$411/month** At $411/month ($4,932/year), this is where Render starts to look expensive compared to alternatives. ![Server Compass container controls showing deployed services](/app-screenshots/feature-container-controls.jpg) ## Render vs VPS Cost Comparison Let's compare Render's pricing to running the same workloads on a VPS: ### Simple SaaS Comparison Platform Monthly Cost Resources **Render** $80/month 4 GB RAM total across services **Hetzner VPS** $7/month 4 GB RAM, 2 vCPU, 40 GB SSD **DigitalOcean Droplet** $24/month 4 GB RAM, 2 vCPU, 80 GB SSD **Annual savings with VPS**: $636-$876 compared to Render ### Production App Comparison Platform Monthly Cost Resources **Render** $255/month Split across multiple services **Hetzner VPS** $15/month 8 GB RAM, 4 vCPU, 160 GB SSD **DigitalOcean Droplet** $48/month 8 GB RAM, 4 vCPU, 160 GB SSD **Annual savings with VPS**: $2,484-$2,880 compared to Render ### Why the Cost Difference? Render charges per service, while a VPS gives you dedicated resources that can run unlimited containers: - **No per-service fees**: Run 10 apps or 1 for the same VPS cost - **Included databases**: PostgreSQL, Redis, MongoDB run free on your VPS - **No bandwidth overages**: Most VPS plans include generous bandwidth - **Full resource access**: Use all available RAM/CPU, not artificial limits ## When Render Makes Sense Despite the cost premium, Render is a good choice in specific scenarios: ### Render Is Worth It For: - **MVP and early-stage startups**: When you need to ship fast and DevOps isn't your focus - **Static sites**: The free tier is genuinely excellent - **Small teams without DevOps expertise**: Zero-config deployments save time - **Predictable billing**: No surprise bills from traffic spikes (unlike Vercel) - **Quick prototypes**: Deploy from GitHub in minutes - **Companies valuing managed services**: Database backups, SSL, and monitoring included ### Render Pricing Is Competitive When: - You're running a single web service with a small database - Your alternative is Heroku (Render is typically 30-50% cheaper) - Time-to-market is more valuable than infrastructure costs - You need preview environments for PRs (built-in feature) ## When to Switch to VPS Consider migrating from Render when: ### Cost Threshold - **Monthly bill exceeds $50-100**: At this point, VPS self-hosting becomes significantly more economical - **Running multiple services**: Each additional service on Render adds $7-25+/month; on a VPS, it's essentially free - **Scaling instances**: Autoscaling costs multiply quickly; a larger VPS is often cheaper ### Technical Requirements - **Need more control**: Custom Nginx configs, specific software versions, system-level tuning - **Running stateful services**: Databases, message queues, and caches are cheaper self-hosted - **Compliance requirements**: Some regulations require dedicated infrastructure - **WebSocket-heavy apps**: VPS gives you persistent connections without limits ### Growth Signals - Your team has or can learn basic Docker/Linux skills - You're deploying more than 3-4 services - Database requirements exceed Basic tier ($20/month) - You want to add services without worrying about incremental costs ## Alternative: Server Compass If Render's pricing doesn't work for your budget but you still want a great deployment experience, [Server Compass](/) offers the best of both worlds: the developer experience of a PaaS with the economics of VPS hosting. ### Server Compass Advantages - **One-time $29 license**: No monthly platform fees, ever - **Deploy to any VPS**: Hetzner, DigitalOcean, Vultr, Linode, or any provider - **Unlimited services**: Run as many apps as your VPS can handle - **Built-in databases**: Deploy PostgreSQL, MySQL, MongoDB, Redis with [one-click templates](/templates) - **GitHub integration**: Push-to-deploy via [GitHub Actions](/features/github-actions) - **Zero-downtime deployments**: Blue-green deployments included - **Visual interface**: No CLI required for day-to-day operations ### Cost Comparison: Render vs Server Compass For the $255/month production setup we calculated earlier: Platform Year 1 Cost Year 2+ Cost **Render** $3,060 $3,060/year **Server Compass + Hetzner** $209 ($29 + $180) $180/year **Server Compass + DigitalOcean** $605 ($29 + $576) $576/year **First year savings**: $2,455-$2,851 **Annual savings after year 1**: $2,484-$2,880 For a detailed comparison, see our [Render vs Server Compass comparison](/compare/render) and [Render alternative guide](/render-alternative). ![Server Compass template library with one-click deployments](/app-screenshots/feature-templates.jpg) ### What You Get with Server Compass - [Docker Stack Wizard](/features/docker-stack-wizard): Visual multi-container deployments - [Framework Detection](/features/framework-detection): Auto-detect 16+ frameworks (Next.js, Django, Laravel, etc.) - [Zero-Downtime Deployments](/features/zero-downtime): Blue-green deployments without configuration - [.env Vault](/features/env-vault): AES-256 encrypted environment variables - [Database Management](/features/db-admin): Visual database admin for PostgreSQL, MySQL, MongoDB - [Automatic SSL](/features/auto-ssl): Let's Encrypt certificates with auto-renewal - [100+ Templates](/templates): One-click deploy for popular services ## Frequently Asked Questions ### Is Render's free tier good enough for production? No. The free tier spins down after 15 minutes of inactivity, causing 30-60 second cold starts. The 90-day PostgreSQL limit means your database gets deleted. Free tier is only suitable for demos, portfolios, and testing. ### How does Render compare to Heroku pricing? Render is typically 30-50% cheaper than Heroku for equivalent resources. A basic Heroku dyno is $7/month (same as Render), but Heroku's database add-ons and other services are significantly more expensive. If you're on Heroku, Render is a reasonable migration target. ### Does Render charge for bandwidth? Render includes 100 GB/month on the free tier and generous bandwidth on paid plans. Unlike Vercel, you won't get surprise bandwidth bills. However, if you exceed limits on higher-traffic sites, overage charges apply at $0.10/GB. ### Can I run multiple apps on one Render service? No. Render's model is one app per service. This is a key cost driver — each additional app adds $7-25+/month. With a VPS, you can run unlimited Docker containers on a single server. ### Is Render worth it for startups? For early-stage MVPs where speed matters more than cost, yes. For scaling startups spending $100+/month on infrastructure, self-hosting becomes more economical. The tipping point is usually when you need multiple services or production-grade databases. ### What's the best Render alternative? It depends on your priorities: - **Lower costs with great DX**: [Server Compass](/) + VPS - **Managed serverless**: Vercel or Cloudflare Pages - **Usage-based pricing**: Railway - **Global edge**: Fly.io ### How hard is it to migrate from Render? Render uses standard Docker and Git-based deployments, making migration relatively straightforward. Your Dockerfiles work anywhere, environment variables can be exported, and databases can be migrated with pg\_dump. Server Compass supports [GitHub Actions CI/CD](/features/github-actions), so you can maintain similar push-to-deploy workflows. ## Conclusion: Is Render Worth It in 2026? Render offers a solid developer experience with predictable pricing — a refreshing alternative to Vercel's usage-based billing. For static sites and small projects, Render's free tier is excellent. For single-app deployments on the Starter tier, $7/month is fair. However, Render's per-service pricing model means costs escalate quickly for real applications. A typical production stack costs $80-250+/month, which is 5-20x more expensive than running the same workload on a VPS. **Render is worth it if**: - You value simplicity over cost optimization - You're running 1-2 services total - You don't have DevOps expertise in-house - Predictable billing is a priority **Consider alternatives if**: - Monthly costs exceed $50-100 - You're running multiple services or databases - Your team can manage basic Docker deployments - Long-term cost savings matter to your business For developers and teams looking to maximize value, [Server Compass](/) provides Render-like deployment experience at VPS prices. One-time $29 license, unlimited deployments, and full control over your infrastructure. Ready to compare? [See our detailed Render comparison](/compare/render) or [explore Render alternatives](/render-alternative). --- **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. --- ## Self-Hosted CI/CD: GitHub Actions + Your VPS (Complete Guide) Source: https://servercompass.app/blog/self-hosted-cicd-github-actions-vps Published: 2026-03-06 Tags: ci-cd, github-actions, self-hosted, docker, vps-deploy, tutorials Build a complete self-hosted CI/CD pipeline using GitHub Actions and your own VPS. Learn SSH deployment, Docker builds, zero-downtime deployments, rollback strategies, and save hundreds on expensive build minutes. Every time you push code, you want it deployed. That's the promise of CI/CD. But if you're self-hosting on a VPS, you've probably discovered the gap: platforms like Vercel and Netlify handle this automatically, while VPS deployments require you to build everything from scratch. The good news? **GitHub Actions gives you 2,000 free minutes per month** on private repos (unlimited on public repos). Combined with your VPS, you get a production-grade CI/CD pipeline that costs nothing beyond your server bill. No expensive build minutes. No vendor lock-in. Complete control over your deployment process. This guide walks you through building a complete self-hosted CI/CD pipeline: from basic SSH deployment to Docker builds, zero-downtime deployments, and automated rollbacks. By the end, you'll have a deployment system that rivals any managed platform. ## Why GitHub Actions + VPS Is the Perfect Combination Before diving into implementation, let's understand why this combination works so well for self-hosted deployments. ### The Build Resource Problem Building applications is resource-intensive. A Next.js build can easily consume 2-4GB of RAM. A Docker image build with multi-stage compilation? Even more. If you're running a $5-10/month VPS with 1-2GB RAM, building on the server itself is often impossible — or it grinds your production app to a halt. GitHub Actions solves this by offloading builds to GitHub's runners: - **2-core CPU** with 7GB RAM per runner - **14GB SSD storage** for build artifacts - **2,000 free minutes/month** on private repos - **Unlimited minutes** on public repos Your VPS stays cool and responsive. The heavy lifting happens on GitHub's infrastructure. You only pull the final artifact (a Docker image or compiled bundle) to your server. ### Automatic Triggers on Every Push GitHub Actions workflows trigger automatically on events like `push` or `pull_request`. Push to `main`, and your deployment starts within seconds. No webhooks to configure. No polling scripts. It just works. ### Built-in Secrets Management GitHub Secrets store your SSH keys, environment variables, and API tokens securely. They're encrypted at rest and only exposed to workflow runs. No plaintext credentials in your repository or server. ## Prerequisites Before we start, make sure you have: - **A VPS** — Any provider works: DigitalOcean, Hetzner, Vultr, Linode, AWS EC2, etc. Ubuntu 22.04+ recommended. - **SSH access** to your VPS with a non-root user that has sudo privileges - **A GitHub repository** with your application code - **Docker installed** on your VPS (we'll cover this if you don't have it) If you don't have Docker installed yet, run this on your VPS: `curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER # Log out and back in for group changes to take effect` ## Step 1: Set Up Your GitHub Actions Workflow Let's start with a basic workflow that deploys on every push to `main`. Create a file at `.github/workflows/deploy.yml` in your repository: `name: Deploy to VPS on: push: branches: [main] workflow_dispatch: # Allow manual triggers jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Deploy to VPS uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | cd /var/www/myapp git pull origin main npm install npm run build pm2 restart myapp` This workflow does the basics: SSH into your server, pull the latest code, install dependencies, build, and restart the app with PM2. But we can do much better. ## Step 2: Configure SSH Deployment Securely The workflow above requires three secrets. Let's set them up properly. ### Generate a Dedicated SSH Key Pair Never use your personal SSH key for CI/CD. Generate a dedicated key pair for deployments: `# On your local machine ssh-keygen -t ed25519 -C "github-actions-deploy" -f ~/.ssh/github_actions_deploy # This creates: # ~/.ssh/github_actions_deploy (private key) # ~/.ssh/github_actions_deploy.pub (public key)` ### Add the Public Key to Your VPS `# Copy the public key to your VPS ssh-copy-id -i ~/.ssh/github_actions_deploy.pub user@your-vps-ip # Or manually append to authorized_keys: cat ~/.ssh/github_actions_deploy.pub | ssh user@your-vps-ip "cat >> ~/.ssh/authorized_keys"` ### Add Secrets to GitHub Go to your repository on GitHub, then **Settings → Secrets and variables → Actions**. Add these secrets: - `VPS_HOST`: Your server's IP address or domain - `VPS_USERNAME`: The SSH username (e.g., `deploy` or `ubuntu`) - `VPS_SSH_KEY`: The **entire contents** of your private key file (`~/.ssh/github_actions_deploy`) ![GitHub Actions workflow configuration with SSH deployment secrets](/app-screenshots/feature-github-actions.jpg) ### Security Best Practices - **Use a dedicated deploy user** — Create a `deploy` user with limited permissions instead of using `root` - **Restrict the SSH key** — In `authorized_keys`, you can limit what the key can do: `# In ~/.ssh/authorized_keys on your VPS: command="/home/deploy/deploy.sh",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... github-actions-deploy` - **Use GitHub Environments** — For production deployments, require approvals before the workflow runs ## Step 3: Docker Build and Push to Registry Building on the VPS is fine for small apps, but Docker images are better for production. They're portable, versioned, and enable zero-downtime deployments. Here's a workflow that builds a Docker image and pushes it to GitHub Container Registry (GHCR): `name: Build and Deploy on: push: branches: [main] workflow_dispatch: env: REGISTRY: ghcr.io IMAGE_NAME: \${{ github.repository }} jobs: build: runs-on: ubuntu-latest permissions: contents: read packages: write outputs: image_tag: \${{ steps.meta.outputs.tags }} steps: - name: Checkout code uses: actions/checkout@v4 - name: Set up Docker Buildx uses: docker/setup-buildx-action@v3 - name: Log in to Container Registry uses: docker/login-action@v3 with: registry: \${{ env.REGISTRY }} username: \${{ github.actor }} password: \${{ secrets.GITHUB_TOKEN }} - name: Extract metadata id: meta uses: docker/metadata-action@v5 with: images: \${{ env.REGISTRY }}/\${{ env.IMAGE_NAME }} tags: | type=sha,prefix= type=raw,value=latest - name: Build and push uses: docker/build-push-action@v5 with: context: . push: true tags: \${{ steps.meta.outputs.tags }} labels: \${{ steps.meta.outputs.labels }} cache-from: type=registry,ref=\${{ env.REGISTRY }}/\${{ env.IMAGE_NAME }}:cache cache-to: type=registry,ref=\${{ env.REGISTRY }}/\${{ env.IMAGE_NAME }}:cache,mode=max deploy: needs: build runs-on: ubuntu-latest steps: - name: Deploy to VPS uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | # Log in to GHCR echo \${{ secrets.GITHUB_TOKEN }} | docker login ghcr.io -u \${{ github.actor }} --password-stdin # Pull the new image docker pull \${{ env.REGISTRY }}/\${{ env.IMAGE_NAME }}:latest # Stop and remove old container docker stop myapp || true docker rm myapp || true # Start new container docker run -d \\ --name myapp \\ --restart unless-stopped \\ -p 3000:3000 \\ --env-file /home/deploy/.env.myapp \\ \${{ env.REGISTRY }}/\${{ env.IMAGE_NAME }}:latest # Clean up old images docker image prune -f` Key features of this workflow: - **Docker layer caching** — Builds are fast because unchanged layers are cached in the registry - **Git SHA tags** — Each image is tagged with its commit SHA for easy rollbacks - **Automatic cleanup** — Old images are pruned to save disk space ### Sample Multi-Stage Dockerfile If you don't have a Dockerfile yet, here's a production-ready example for a Next.js application: `# Stage 1: Dependencies FROM node:20-alpine AS deps WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci --only=production # Stage 2: Build FROM node:20-alpine AS builder WORKDIR /app COPY package.json package-lock.json ./ RUN npm ci COPY . . RUN npm run build # Stage 3: Production FROM node:20-alpine AS runner WORKDIR /app ENV NODE_ENV=production # Create non-root user RUN addgroup --system --gid 1001 nodejs RUN adduser --system --uid 1001 nextjs # Copy built assets COPY --from=builder /app/public ./public COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./ COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static USER nextjs EXPOSE 3000 ENV PORT=3000 CMD ["node", "server.js"]` Need a Dockerfile for your specific framework? Use our [GitHub Actions Generator](/tools/github-actions-generator) or [Dockerfile Generator](https://docker.servercompass.app/) to create one automatically. ## Step 4: Zero-Downtime Deployment Script The basic deployment above has a problem: there's a brief period where your app is unavailable between stopping the old container and starting the new one. For production apps, you need **zero-downtime deployment**. The solution is a **blue-green deployment**: start the new container alongside the old one, verify it's healthy, then switch traffic over. Create a deployment script on your VPS at `/home/deploy/deploy.sh`: `#!/bin/bash set -e APP_NAME="myapp" IMAGE="ghcr.io/your-username/your-repo:latest" PORT=3000 HEALTH_ENDPOINT="/" MAX_HEALTH_CHECKS=10 HEALTH_CHECK_INTERVAL=3 # Colors for output RED='\\033[0;31m' GREEN='\\033[0;32m' NC='\\033[0m' # No Color log() { echo -e "\$[DEPLOY]\$ $1" } error() { echo -e "\$[ERROR]\$ $1" exit 1 } # Pull the latest image log "Pulling latest image..." docker pull "$IMAGE" # Find an available port for staging STAGING_PORT=$((PORT + 1000)) # Start staging container log "Starting staging container on port $STAGING_PORT..." docker run -d \\ --name "\$-staging" \\ --restart unless-stopped \\ -p "\$:3000" \\ --env-file "/home/deploy/.env.\$" \\ "$IMAGE" # Wait for container to be ready log "Waiting for container to start..." sleep 5 # Health check log "Running health checks..." HEALTHY=false for i in $(seq 1 $MAX_HEALTH_CHECKS); do HTTP_CODE=$(curl -s -o /dev/null -w "%" "http://localhost:\$\$" || echo "000") if [ "$HTTP_CODE" = "200" ]; then HEALTHY=true log "Health check passed ($i/$MAX_HEALTH_CHECKS)" break else log "Health check attempt $i/$MAX_HEALTH_CHECKS (HTTP $HTTP_CODE)" sleep $HEALTH_CHECK_INTERVAL fi done if [ "$HEALTHY" = false ]; then error "Health checks failed. Rolling back..." docker stop "\$-staging" || true docker rm "\$-staging" || true exit 1 fi # Stop old production container log "Stopping old production container..." docker stop "\$" 2>/dev/null || true docker rm "\$" 2>/dev/null || true # Rename staging to production log "Promoting staging to production..." docker stop "\$-staging" docker rm "\$-staging" # Start fresh on the production port docker run -d \\ --name "\$" \\ --restart unless-stopped \\ -p "\$:3000" \\ --env-file "/home/deploy/.env.\$" \\ "$IMAGE" # Final health check sleep 3 HTTP_CODE=$(curl -s -o /dev/null -w "%" "http://localhost:\$\$" || echo "000") if [ "$HTTP_CODE" = "200" ]; then log "Deployment successful! App is live on port $PORT" else error "Final health check failed (HTTP $HTTP_CODE). Manual intervention required." fi # Cleanup old images log "Cleaning up old images..." docker image prune -f log "Done!"` Make the script executable: `chmod +x /home/deploy/deploy.sh` Update your workflow to use the script: `- name: Deploy to VPS uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | echo \${{ secrets.GITHUB_TOKEN }} | docker login ghcr.io -u \${{ github.actor }} --password-stdin /home/deploy/deploy.sh` ## Step 5: Rollback Strategy Things go wrong. A bad deploy can take down your production app. You need a fast, reliable way to roll back to the previous version. ### Automatic Rollback on Failure The deployment script above already handles this: if health checks fail, it removes the staging container and keeps the old production container running. But what if the new container passes health checks but has a bug that surfaces later? ### Manual Rollback Workflow Create a separate workflow for manual rollbacks. This lets you quickly revert to any previous version: `name: Rollback on: workflow_dispatch: inputs: commit_sha: description: 'Git commit SHA to rollback to' required: true type: string env: REGISTRY: ghcr.io IMAGE_NAME: \${{ github.repository }} jobs: rollback: runs-on: ubuntu-latest steps: - name: Rollback to previous version uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | IMAGE="\${{ env.REGISTRY }}/\${{ env.IMAGE_NAME }}:\${{ github.event.inputs.commit_sha }}" echo "Rolling back to $IMAGE" # Log in and pull the specific version echo \${{ secrets.GITHUB_TOKEN }} | docker login ghcr.io -u \${{ github.actor }} --password-stdin docker pull "$IMAGE" # Stop current container docker stop myapp || true docker rm myapp || true # Start the rollback version docker run -d \\ --name myapp \\ --restart unless-stopped \\ -p 3000:3000 \\ --env-file /home/deploy/.env.myapp \\ "$IMAGE" echo "Rollback complete. Running version: \${{ github.event.inputs.commit_sha }}"` To rollback, go to **Actions → Rollback → Run workflow** and enter the commit SHA you want to deploy. Since every build is tagged with its SHA, you can roll back to any version that's still in the registry. ### Keep Multiple Versions in the Registry By default, the workflow tags images with both `latest` and the commit SHA. This means you always have a history of deployable versions. To prevent storage costs from growing indefinitely, set up a retention policy: `# Add to your build job: - name: Delete old package versions uses: actions/delete-package-versions@v5 with: package-name: 'your-app-name' package-type: 'container' min-versions-to-keep: 10 delete-only-untagged-versions: 'true'` ## Example Workflows for Common Scenarios ### Node.js Deployment (Without Docker) If you're not using Docker, here's a workflow that deploys a Node.js app directly with PM2: `name: Deploy Node.js App on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - name: Deploy via SSH uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | cd /var/www/myapp # Fetch latest changes git fetch origin main git reset --hard origin/main # Install dependencies npm ci --only=production # Build the app npm run build # Reload with PM2 (zero-downtime) pm2 reload myapp --update-env # Save PM2 process list pm2 save` ### Docker Compose Deployment For apps with multiple services (app + database + cache), use Docker Compose: `name: Deploy with Docker Compose on: push: branches: [main] jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Copy files to VPS uses: appleboy/scp-action@v0.1.7 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} source: "docker-compose.yml,docker-compose.prod.yml" target: "/home/deploy/myapp" - name: Deploy uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | cd /home/deploy/myapp # Pull latest images docker compose -f docker-compose.yml -f docker-compose.prod.yml pull # Deploy with zero downtime docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d --remove-orphans # Clean up docker image prune -f` ### Multi-Stage Build with Testing Run tests before deploying to catch issues early: `name: Test, Build, and Deploy on: push: branches: [main] pull_request: branches: [main] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup Node.js uses: actions/setup-node@v4 with: node-version: '20' cache: 'npm' - name: Install dependencies run: npm ci - name: Run linter run: npm run lint - name: Run tests run: npm test - name: Run type check run: npm run type-check build: needs: test if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest # ... build steps from earlier deploy: needs: build if: github.ref == 'refs/heads/main' runs-on: ubuntu-latest # ... deploy steps from earlier` ## Server Compass Auto-Deploy Feature Everything above works great, but it's a lot of YAML to write and maintain. If you'd rather skip the manual setup, [Server Compass's Auto-Deploy feature](/features/auto-deploy) generates production-ready GitHub Actions workflows automatically. ![Server Compass auto-deploy feature showing automated GitHub Actions deployment](/app-screenshots/feature-auto-deploy.jpg) Here's what Server Compass handles for you: - **Workflow generation** — Creates a complete `.github/workflows` file based on your framework (Next.js, Django, Go, etc.) - **Dockerfile generation** — Auto-detects your framework and generates an optimized multi-stage Dockerfile - **SSH key setup** — Generates an Ed25519 key pair, adds the public key to your VPS, and stores the private key as a GitHub Secret - **Secret encryption** — Encrypts your environment variables with libsodium sealed boxes before storing them in GitHub Secrets - **Zero-downtime deployment** — Built-in blue-green deployment with health checks - **Real-time tracking** — Watch your deployment progress without switching to GitHub The setup takes about 60 seconds: connect your GitHub account, select a repository, and deploy. Server Compass commits the workflow file to your repo and triggers the first deployment automatically. Read the full deep-dive: [How Server Compass Uses GitHub Actions for Zero-Downtime VPS Deployments](/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments) ## Comparison: GitHub Actions vs Vercel/Netlify Builds How does a self-hosted CI/CD pipeline compare to managed platforms? Let's break it down. Feature GitHub Actions + VPS Vercel Netlify **Build minutes (free)** 2,000/month 6,000/month 300/month **Build minutes (paid)** $0.008/min $0.01/min $0.02/min **Concurrent builds** 20 (free tier) 1 (free), 12 (Pro) 1 (free), 3 (Pro) **Custom domains** Unlimited 50 100 **Server-side code** Full control Serverless only Serverless only **Database access** Direct (same server) External only External only **Persistent storage** Yes (disk) No No **WebSockets** Yes Limited No **Long-running processes** Yes No (10s limit) No (10s limit) **Vendor lock-in** None Medium-High Medium ### When to Choose GitHub Actions + VPS - You need full server control (databases, cron jobs, WebSockets) - You want to avoid per-seat pricing ($20/user/month on Vercel) - Your app has long-running processes or background workers - You need persistent file storage - You want to run multiple apps on one server - You're cost-conscious and willing to manage infrastructure ### When Vercel/Netlify Might Be Better - You're building a static site or JAMstack app - You need global edge deployment out of the box - You don't want to manage any infrastructure - Your team is small and cost isn't a concern ## Frequently Asked Questions ### How many free GitHub Actions minutes do I actually get? **2,000 minutes/month** for private repositories on the free tier. Public repositories get **unlimited minutes**. If you need more, GitHub Pro includes 3,000 minutes, and Team/Enterprise plans include more. ### Can I use my VPS as a GitHub Actions runner? Yes! You can install a [self-hosted runner](https://docs.github.com/en/actions/hosting-your-own-runners) on your VPS. This gives you unlimited minutes but uses your server's resources for builds. Best for powerful servers (4+ GB RAM) or when you need access to local services during the build. ### How do I handle environment variables securely? Store sensitive values in **GitHub Secrets**. For runtime env vars, create a `.env` file on your VPS (e.g., `/home/deploy/.env.myapp`) and reference it with `--env-file` when running Docker containers. ### How do I run database migrations during deployment? Add a migration step to your deployment script: `# Before starting the new container: docker run --rm \\ --env-file /home/deploy/.env.myapp \\ $IMAGE \\ npm run migrate` ### Can I deploy multiple apps to the same VPS? Absolutely. Each app gets its own container, its own port, and its own env file. Use a reverse proxy like Nginx or Traefik to route traffic based on domain names. Server Compass includes built-in [Traefik integration](/features/domain-management) for automatic routing and SSL. ### How do I monitor deployment status? GitHub Actions provides real-time logs in the Actions tab. For notifications, add a Slack or Discord step to your workflow: `- name: Notify Slack if: always() uses: 8398a7/action-slack@v3 with: status: \${{ job.status }} fields: repo,message,commit,author env: SLACK_WEBHOOK_URL: \${{ secrets.SLACK_WEBHOOK }}` ### What happens if I push twice quickly? By default, both deployments run in parallel, which can cause issues. Add concurrency settings to cancel in-progress runs: `concurrency: group: deploy-\${{ github.ref }} cancel-in-progress: true` ## Conclusion Self-hosted CI/CD with GitHub Actions and your VPS is a powerful combination. You get the convenience of automatic deployments, the flexibility of full server control, and significant cost savings compared to managed platforms. The key components: 1. **GitHub Actions workflows** for build automation and deployment triggers 2. **Secure SSH deployment** with dedicated keys stored in GitHub Secrets 3. **Docker images** for portable, versioned deployments 4. **Blue-green deployment** for zero downtime 5. **Rollback strategy** with SHA-tagged images If you want to skip the manual setup, try [Server Compass](/). It generates production-ready GitHub Actions workflows, handles SSH key management, encrypts your secrets, and gives you a visual interface for managing deployments. One-time purchase, no subscription. **Related resources:** - [GitHub Actions Workflow Generator](/tools/github-actions-generator) — Create custom workflows interactively - [Dockerfile Generator](https://docker.servercompass.app/) — Generate optimized Dockerfiles for your framework - [Auto-Deploy Feature](/features/auto-deploy) — Automatic deployments on every git push - [How Server Compass Uses GitHub Actions](/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments) — Deep dive into the implementation --- **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-Hosted DevOps Tools for Small Teams (2026) Source: https://servercompass.app/blog/self-hosted-devops-tools-small-teams Published: 2026-03-06 Tags: self-hosted, devops, ci-cd, monitoring, docker A comprehensive guide to the best self-hosted DevOps tools for small teams in 2026. From CI/CD pipelines to monitoring, git hosting, and container registries, build a complete DevOps stack on your own infrastructure for a fraction of the cost. Small development teams face a familiar dilemma: enterprise DevOps tools are expensive and complex, while cobbling together free SaaS tiers leads to fragmented workflows and surprise bills. In 2026, the answer is increasingly clear — self-hosted DevOps tools give you professional-grade capabilities at a fraction of the cost, with complete control over your data and infrastructure. This guide covers the best self-hosted DevOps tools across every category, with specific recommendations for teams of 2-10 developers. We will show you how to build a complete DevOps stack on a single VPS for under $20/month — replacing thousands of dollars in SaaS subscriptions. ## Why Self-Host Your DevOps Stack Before diving into specific tools, let us address why self-hosting makes sense for small teams in 2026: ### Cost Control SaaS DevOps tools charge per user, per seat, per build minute, or per feature. A typical small team using GitHub Actions, Datadog, PagerDuty, and a managed container registry can easily spend $500-2,000/month. Self-hosted alternatives running on a $10-20/month VPS deliver the same functionality for 95% less. ### Data Sovereignty Your CI/CD pipelines process source code, secrets, and deployment credentials. Your monitoring systems collect detailed application metrics and logs. With self-hosted tools, this sensitive data never leaves infrastructure you control — critical for compliance requirements and client trust. ### No Vendor Lock-in When CircleCI changes pricing or Datadog sunsets a feature, you are stuck. Self-hosted tools run on standard infrastructure. Migrate between VPS providers, move to Kubernetes, or switch tools entirely — your choice, your timeline. ### Customization Self-hosted tools are typically open source. Need a custom integration? Add it. Want to modify the UI? Fork and change it. You are not limited to whatever features the vendor prioritizes. ## Categories of DevOps Tools A complete DevOps stack for a small team typically includes: - **Deployment Platform** — Deploy and manage applications on your servers with a visual interface - **CI/CD** — Automated testing, building, and deployment pipelines - **Monitoring** — Uptime checks, performance metrics, and alerting - **Logging** — Centralized log aggregation and search - **Container Registry** — Store and distribute Docker images - **Git Hosting** — Version control with code review and issue tracking Let us explore the best self-hosted options in each category. ## Deployment Platforms Modern deployment platforms provide Heroku/Vercel-like experiences on your own infrastructure. They handle Docker builds, SSL certificates, reverse proxies, and zero-downtime deployments. ### Server Compass [Server Compass](/) is a desktop application that connects to your VPS via SSH to deploy and manage applications. Unlike web-based platforms, nothing runs on your server except your actual applications — no dashboard, no agent, no background processes consuming resources. **Best for:** Teams who want a polished deployment experience without giving up server resources. Perfect for developers coming from Vercel or Railway who want similar UX on their own VPS. **Key features:** - [Auto-detection for 16+ frameworks](/features/framework-detection) (Next.js, Django, Laravel, Go, etc.) - [Zero-downtime blue-green deployments](/features/zero-downtime) - [100+ one-click deployment templates](/templates) - Visual database management, log streaming, and environment variable vault - GitHub Actions integration for CI/CD **Resource requirements:** None on server (desktop app). VPS needs 1GB+ RAM for small deployments. **Pricing:** $19 one-time purchase. No subscriptions, unlimited servers. ![Server Compass dashboard showing running containers with CPU and memory usage](/app-screenshots/feature-container-status.jpg) ### Coolify Coolify is a self-hosted Heroku/Netlify alternative that runs as a web application on your server. It provides a browser-based dashboard for deploying applications, databases, and services. **Best for:** Teams who prefer a web-based interface and do not mind dedicating server resources to the dashboard. **Key features:** - Git-based deployments from GitHub, GitLab, or Bitbucket - Built-in database provisioning (PostgreSQL, MySQL, MongoDB, Redis) - Automatic SSL via Let's Encrypt - Docker Compose support **Resource requirements:** 2GB+ RAM minimum (dashboard runs on your VPS). **Pricing:** Free and open source. ### CapRover CapRover is a mature PaaS platform that uses Docker Swarm for container orchestration. It includes a one-click app marketplace and supports custom Dockerfiles. **Best for:** Teams deploying many applications who want a Heroku-like buildpack experience. **Key features:** - One-click app marketplace with 200+ templates - Automatic SSL certificates - Docker Swarm clustering for high availability - CLI and web interface **Resource requirements:** 1GB+ RAM (uses Docker Swarm). **Pricing:** Free and open source. ## CI/CD Platforms Continuous integration and deployment pipelines automate testing and deployment. While GitHub Actions works well for many teams, self-hosted CI/CD gives you unlimited build minutes and complete control over your build environment. ### Drone CI [Drone CI](/templates/drone) is a container-native CI/CD platform that integrates seamlessly with Gitea, GitHub, GitLab, and Bitbucket. Pipelines are defined in simple YAML files, and each step runs in an isolated Docker container. **Best for:** Teams using Docker who want simple, declarative pipelines with minimal configuration. **Key features:** - Container-native — every step runs in isolation - Simple YAML configuration - Built-in secrets management - Plugins for deployment, notifications, and integrations - Scales horizontally with additional runners **Resource requirements:** 512MB RAM for server, 1GB+ per runner. **Example pipeline:** ``` kind: pipeline type: docker name: default steps: - name: test image: node:20 commands: - npm ci - npm test - name: build image: node:20 commands: - npm run build - name: deploy image: plugins/ssh settings: host: from_secret: deploy_host username: deploy key: from_secret: deploy_key script: - cd /app && git pull && docker compose up -d --build ``` ### Woodpecker CI Woodpecker is a community fork of Drone CI that remains fully open source (Drone has some proprietary features). It maintains compatibility with Drone plugins while adding community-driven improvements. **Best for:** Teams who want Drone's simplicity with a fully open source license. **Key features:** - 100% compatible with Drone plugins - Multi-platform support (Linux, Windows, macOS) - Matrix builds for testing across versions - Active community development **Resource requirements:** 256MB RAM for server, 512MB+ per agent. ### Gitea Actions [Gitea](/templates/gitea) now includes built-in Actions that are compatible with GitHub Actions workflows. If you are already self-hosting Gitea for git, you get CI/CD included. **Best for:** Teams already using Gitea who want integrated CI/CD without additional tools. **Key features:** - GitHub Actions workflow compatibility - Reuse existing GitHub Actions workflows - Integrated with Gitea repositories - Self-hosted runners **Resource requirements:** Part of Gitea (512MB+ RAM total). ## Monitoring Tools Monitoring tells you when things break and helps you understand system behavior. A good monitoring stack includes uptime checks, metrics collection, and alerting. ### Uptime Kuma [Uptime Kuma](/templates/uptime-kuma) is a beautiful, self-hosted uptime monitoring tool. It checks your services and alerts you via email, Slack, Discord, Telegram, or dozens of other notification channels when something goes down. **Best for:** Every team. This is the must-have monitoring tool for any self-hosted stack. **Key features:** - HTTP(s), TCP, DNS, Docker container, and more monitor types - 90+ notification services (Slack, Discord, email, PagerDuty, etc.) - Beautiful status pages for public display - Multi-language support - 2FA authentication **Resource requirements:** 128MB RAM (extremely lightweight). **Replaces:** UptimeRobot ($7-37/month), Pingdom ($10-249/month), StatusCake ($20-200/month). ![Server Compass template gallery showing monitoring tools including Uptime Kuma](/app-screenshots/feature-templates.jpg) ### Grafana [Grafana](/templates/grafana) is the industry standard for visualization and dashboards. It connects to dozens of data sources and lets you build beautiful, interactive dashboards for any metrics. **Best for:** Teams who want detailed visibility into application and infrastructure performance. **Key features:** - Support for 100+ data sources - Customizable dashboards with drag-and-drop panels - Alerting with multiple notification channels - Templating for dynamic dashboards - Annotations to mark deployments and events **Resource requirements:** 256MB RAM minimum, 512MB+ recommended. ### Prometheus [Prometheus](/templates/prometheus) is the standard for metrics collection in modern infrastructure. It scrapes metrics from your applications and stores them in a time-series database for querying and alerting. **Best for:** Teams running containerized applications who need detailed performance metrics. **Key features:** - Pull-based metrics collection - Powerful PromQL query language - Built-in alerting with Alertmanager - Service discovery for dynamic environments - Excellent Docker and Kubernetes integration **Resource requirements:** 512MB-2GB RAM depending on metrics volume. **Replaces:** Datadog ($15-27/host/month), New Relic ($0.30/GB ingested), Dynatrace ($69/host/month). ## Logging Solutions Centralized logging aggregates logs from all your applications and services into a single searchable interface. Essential for debugging distributed systems. ### Loki Loki is Grafana's log aggregation system, designed to be cost-effective and easy to operate. Unlike traditional log solutions, Loki only indexes metadata (labels), making it extremely efficient. **Best for:** Teams already using Grafana who want integrated logging without the complexity of Elasticsearch. **Key features:** - Native Grafana integration - Label-based indexing (efficient storage) - LogQL query language (similar to PromQL) - Supports Docker, Kubernetes, and systemd - Much lower resource usage than Elasticsearch **Resource requirements:** 256MB RAM minimum. ### Graylog Graylog is a full-featured log management platform built on Elasticsearch and MongoDB. It provides powerful search, dashboards, and alerting for log data. **Best for:** Teams who need advanced log analysis, compliance features, or are processing high log volumes. **Key features:** - Powerful full-text search - Stream processing and pipelines - Role-based access control - Compliance and audit logging - Alerting and notifications **Resource requirements:** 4GB+ RAM (includes Elasticsearch and MongoDB). **Replaces:** Splunk ($150/GB/month), Loggly ($79-279/month), Papertrail ($7-230/month). ## Container Registries Docker registries store and distribute your container images. Self-hosting gives you unlimited storage and complete control over your images. ### Harbor Harbor is an enterprise-grade container registry with security scanning, RBAC, and replication. It is the most feature-complete self-hosted registry available. **Best for:** Teams who need security scanning, access control, or multi-site replication. **Key features:** - Built-in vulnerability scanning (Trivy) - Role-based access control - Image signing and verification - Replication between registries - Garbage collection - Helm chart repository **Resource requirements:** 2GB+ RAM. ### Distribution (Docker Registry) Distribution (formerly Docker Registry) is the official open-source registry from Docker. It is simple, reliable, and requires minimal resources. **Best for:** Teams who just need basic image storage without advanced features. **Key features:** - Official Docker project - Simple configuration - S3/Azure/GCS storage backends - Basic authentication - Minimal resource usage **Resource requirements:** 128MB RAM. **Replaces:** Docker Hub Pro ($7/user/month), AWS ECR ($0.10/GB/month + transfer), GCR ($0.10/GB/month). ## Git Hosting Self-hosted git gives you unlimited private repositories, full control over your code, and integrated [project management](https://1devtool.com/features/multi-account-git) features. ### Gitea [Gitea](/templates/gitea) is a lightweight, fast git server written in Go. It provides GitHub-like features including pull requests, issues, wikis, and now CI/CD via Gitea Actions. **Best for:** Most small teams. Gitea offers the best balance of features and resource efficiency. **Key features:** - Pull requests with code review - Issues and project boards - Gitea Actions (GitHub Actions compatible) - Wikis and documentation - OAuth2 and LDAP authentication - Webhooks and integrations - Package registry **Resource requirements:** 256MB RAM minimum (remarkably lightweight). ### GitLab CE GitLab Community Edition is a full DevOps platform including git hosting, CI/CD, container registry, and project management. It is feature-rich but resource-intensive. **Best for:** Teams who want an all-in-one platform and have the server resources to run it. **Key features:** - Complete DevOps platform in one tool - Built-in CI/CD with Auto DevOps - Container registry included - Issue tracking and boards - Wikis and snippets - Security scanning in pipelines **Resource requirements:** 4GB+ RAM minimum (8GB recommended). **Replaces:** GitHub Team ($4/user/month), GitLab.com Premium ($29/user/month), Bitbucket ($3-6/user/month). ## Comparison Table Here is a quick reference comparing self-hosted DevOps tools by category: Category Tool RAM Required Ease of Setup Best For Deployment Server Compass 0 (desktop app) Easy Best UX, no server overhead Coolify 2GB+ Easy Web-based dashboard CapRover 1GB+ Medium Heroku-like buildpacks CI/CD Drone CI 512MB+ Easy Docker-native pipelines Woodpecker CI 256MB+ Easy Fully open source Drone Gitea Actions Part of Gitea Easy GitHub Actions compatible Monitoring Uptime Kuma 128MB Very Easy Uptime monitoring Grafana 256MB+ Medium Dashboards and visualization Prometheus 512MB+ Medium Metrics collection Logging Loki 256MB+ Easy Lightweight, Grafana integration Graylog 4GB+ Complex Advanced log analysis Registry Harbor 2GB+ Medium Enterprise features, scanning Distribution 128MB Easy Simple image storage Git Hosting Gitea 256MB Easy Lightweight, feature-rich GitLab CE 4GB+ Medium All-in-one platform ## Recommended Stack for Small Teams Based on our experience helping thousands of developers self-host, here is the stack we recommend for teams of 2-10 developers: ### The Lean Stack ($10/month VPS) For teams just starting out or with modest requirements: - **Deployment:** [Server Compass](/) — No server resources needed - **CI/CD:** GitHub Actions (free tier) or Woodpecker CI - **Monitoring:** [Uptime Kuma](/templates/uptime-kuma) - **Git:** GitHub free tier or [Gitea](/templates/gitea) **Total RAM required:** ~500MB for self-hosted tools, leaving plenty for your applications. ### The Complete Stack ($20/month VPS) For teams who want full observability and complete infrastructure independence: - **Deployment:** [Server Compass](/) - **CI/CD:** [Drone CI](/templates/drone) or Gitea Actions - **Monitoring:** [Uptime Kuma](/templates/uptime-kuma) + [Prometheus](/templates/prometheus) + [Grafana](/templates/grafana) - **Logging:** Loki + Grafana - **Registry:** Distribution or Harbor - **Git:** [Gitea](/templates/gitea) **Total RAM required:** ~2-3GB for tools, 4GB VPS recommended. ### The Enterprise Stack ($40-60/month) For larger teams or those with compliance requirements: - **All-in-one:** GitLab CE (includes git, CI/CD, and registry) - **Monitoring:** Prometheus + Grafana + Alertmanager - **Logging:** Graylog - **Registry:** Harbor (for security scanning) **Total RAM required:** 8-16GB, consider dedicated monitoring server. ## How to Get Started Ready to build your self-hosted DevOps stack? Here is the fastest path: ### Step 1: Get a VPS Choose a VPS provider. We recommend: - **Hetzner** — Best value in Europe (4GB RAM, 2 vCPU for $5.50/month) - **DigitalOcean** — Reliable with good documentation (4GB RAM for $24/month) - **Vultr** — Global locations with competitive pricing (4GB RAM for $24/month) - **Linode** — Consistent performance (4GB RAM for $24/month) For most small teams, a 4GB RAM VPS ($10-25/month) is sufficient to run all DevOps tools plus several applications. ### Step 2: Install Docker All the tools we recommend run in Docker containers. Install Docker on your VPS: ``` curl -fsSL https://get.docker.com | sh sudo usermod -aG docker $USER ``` ### Step 3: Deploy Your Tools Use [Server Compass](/) to deploy DevOps tools with one click. Connect your VPS and browse the [template library](/templates): - [Deploy Uptime Kuma](/templates/uptime-kuma) — Start monitoring in 60 seconds - [Deploy Gitea](/templates/gitea) — Self-hosted GitHub alternative - [Deploy Drone CI](/templates/drone) — Container-native CI/CD - [Deploy Grafana](/templates/grafana) — Dashboards and visualization - [Deploy Prometheus](/templates/prometheus) — Metrics collection ![Server Compass deployment history showing successful deployments](/app-screenshots/feature-deploy-history.jpg) ### Step 4: Connect Your Tools Once deployed, connect your tools together: 1. Point Grafana to Prometheus as a data source 2. Configure Drone/Woodpecker to authenticate with Gitea 3. Set up Uptime Kuma monitors for all your services 4. Add notification channels (Slack, Discord, email) to Uptime Kuma ## Cost Savings vs Cloud Tools Let us calculate the actual savings for a team of 5 developers: ### SaaS DevOps Costs (Monthly) Service Tool Cost Git Hosting GitHub Team $20/month (5 users) CI/CD GitHub Actions $40/month (extra minutes) Monitoring Datadog $75/month (5 hosts) Uptime Monitoring Pingdom $15/month Logging Papertrail $35/month Container Registry Docker Hub $35/month (5 users) **Total** **$220/month** ### Self-Hosted Costs (Monthly) Service Tool Cost VPS (4GB RAM) Hetzner $10/month Deployment Tool Server Compass $1.58/month (amortized) All DevOps Tools Self-hosted $0 **Total** **$11.58/month** **Annual savings: $2,500+** That is money you can invest in your product, your team, or your infrastructure. And you get complete control over your data and tools. ## Frequently Asked Questions ### How much maintenance do self-hosted tools require? Most modern self-hosted tools are designed to run unattended. With Docker, updates are as simple as pulling a new image and restarting the container. Plan for 1-2 hours per month for routine updates and monitoring. ### Is self-hosting secure? Self-hosting can be more secure than SaaS because your data never leaves your infrastructure. The key is following security best practices: keep software updated, use strong passwords, enable firewalls, and configure SSL. Tools like [Server Compass](/) include built-in [security auditing](/features/security-audit) to help you maintain a secure server. ### Can self-hosted tools scale? Yes. All the tools we recommend can scale horizontally by adding more servers. Drone CI supports multiple runners, Gitea can be clustered, and monitoring tools can be federated. For most small teams, vertical scaling (bigger VPS) is simpler and sufficient. ### How do I handle backups? Docker volumes make backups straightforward. Use `docker cp` or volume backup tools to copy data. For databases, use native backup tools (pg\_dump, mysqldump). Store backups in S3-compatible storage for offsite redundancy. ### Should I still use GitHub Actions? GitHub Actions free tier (2,000 minutes/month) works great for many teams. Self-host CI/CD when you need unlimited build minutes, want to avoid vendor lock-in, or have security requirements that prevent using third-party CI. You can also use GitHub Actions with self-hosted runners to get the best of both worlds. ### Can I run all these tools with Docker Compose? Absolutely. Each tool we mentioned can be deployed with a simple `docker-compose.yml` file. Or use [Server Compass](/) for one-click deployments with automatic SSL and domain configuration. ### How do I onboard my team? Most self-hosted tools include user management. Gitea and GitLab support SSO via OAuth2/SAML. Grafana supports LDAP and OAuth. For smaller teams, simple username/password authentication works fine. ## Conclusion Building a self-hosted DevOps stack in 2026 is easier than ever. The tools are mature, well-documented, and designed for teams without dedicated DevOps engineers. For a small team, you can replace thousands of dollars in annual SaaS costs with a single $10-20/month VPS. Start small. Deploy [Uptime Kuma](/templates/uptime-kuma) for monitoring. Add [Gitea](/templates/gitea) when you want to own your git hosting. Expand to [Drone CI](/templates/drone) for unlimited build minutes. Each tool you self-host is one less vendor dependency and one more capability under your control. Ready to get started? [Download Server Compass](/) and deploy your first DevOps tool in minutes. One-time purchase, no subscriptions — just powerful self-hosted infrastructure on your terms. --- **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. --- ## Self-Hosted Vercel Alternative: Complete Guide (2026) Source: https://servercompass.app/blog/self-hosted-vercel-alternative-complete-guide Published: 2026-03-06 Tags: vercel-alternative, self-hosted, deployment, comparison, docker The complete guide to self-hosted Vercel alternatives. Compare Server Compass, Coolify, and CapRover. Learn how to migrate from Vercel, calculate real cost savings, and deploy with the same developer experience on your own VPS. Vercel changed how developers deploy web applications. The git-push-to-deploy workflow, instant preview deployments, and zero-config SSL made it the gold standard for developer experience. But as your traffic grows, so does your bill. What starts as a convenient $20/month quickly balloons to $200, $500, or even $2,000+ monthly as bandwidth overages, serverless function executions, and build minutes add up. The solution? A **self-hosted Vercel alternative** that gives you the same developer experience on your own infrastructure. You keep the one-click deploys, Git integration, and automatic SSL—but pay a flat $5-50/month for your VPS instead of usage-based pricing that punishes your success. This guide covers everything you need to know about self-hosted Vercel alternatives in 2026: the top platforms compared, step-by-step migration instructions, real cost savings calculations, and how to choose the right solution for your needs. ## Why Developers Want Vercel UX Without Vercel Pricing Vercel's pricing model has a fundamental problem: it charges you more when you succeed. A viral blog post, a successful Product Hunt launch, or simply growing your user base can transform your hosting costs overnight. Here's what developers commonly experience: - **Bandwidth overages**: After 1TB on Pro ($20/month), you pay $40 per 100GB. A high-traffic site can easily rack up $400-800/month in bandwidth alone. - **Serverless function costs**: After 1M executions, additional invocations cost $0.60 per million. API-heavy apps can hit $100-300/month just in function costs. - **Build minute limits**: The 6,000 minutes included on Pro sound generous until you have a monorepo with multiple apps deploying on every commit. - **Team seat pricing**: $20/user/month adds up fast. A 5-person team pays $100/month before any usage. The frustration is real: you love Vercel's workflow, but you can't afford it at scale. Self-hosted alternatives solve this by decoupling the deployment experience from the infrastructure costs. You get the same `git push` workflow, the same preview deployments, the same automatic SSL—but on a VPS that costs $5-50/month regardless of traffic. ## What You Need from a Self-Hosted Vercel Alternative Not every deployment tool qualifies as a true Vercel alternative. To match Vercel's developer experience, a self-hosted platform needs these core capabilities: ### One-Click Deploys Vercel's magic starts with zero-config deployment. Connect your repo, and Vercel figures out your framework, build commands, and output directory automatically. A real alternative needs the same: framework detection that recognizes Next.js, React, Vue, Svelte, Django, Flask, Laravel, Go, Rust, and more—then configures everything without manual setup. ### Git Integration Push to main, deploy to production. Push to a feature branch, get a preview URL. This Git-centric workflow is non-negotiable. Your alternative should integrate with GitHub, GitLab, or Bitbucket and trigger deployments automatically on every push. ### Automatic SSL Manual certificate management is a relic of the past. Your self-hosted alternative should provision Let's Encrypt certificates automatically and renew them before expiry. Connect a domain, SSL works—no command line required. ### Preview Deployments Every pull request should get its own URL for testing and review. This is one of Vercel's most loved features, and any serious alternative needs to replicate it. Unique URLs per branch, automatic cleanup when branches are merged or deleted. ### Zero-Downtime Updates Deploying shouldn't mean downtime. Blue-green or rolling deployments should be the default, not an enterprise add-on. Your new version spins up, health checks pass, traffic switches over—users never notice the update. ### Environment Variable Management Secrets belong in a vault, not a `.env` file committed to Git. Your alternative should offer secure environment variable storage, ideally with encryption at rest and per-environment configurations (development, staging, production). ## Top Self-Hosted Vercel Alternatives in 2026 Three platforms stand out as the best self-hosted Vercel alternatives. Each takes a different approach to balancing features, complexity, and cost. ### 1\. Server Compass — The Closest to Vercel UX [Server Compass](/) is a desktop application that brings Vercel's deployment experience to your own VPS. Instead of a web-based control panel, you get a native Mac, Windows, or Linux app that connects to any VPS over SSH and handles all the complexity behind a visual interface. ![Server Compass deployment history showing zero-downtime blue-green deployments](/app-screenshots/feature-deploy-history.jpg) #### Key Features - **Framework Detection**: Auto-detects 16+ frameworks including Next.js, Nuxt, SvelteKit, Remix, Astro, Django, Flask, FastAPI, Laravel, Rails, Go, Rust, and more. See [framework detection](/features/framework-detection) for the full list. - **GitHub Actions CI/CD**: Generates complete [GitHub Actions workflows](/features/github-actions) that build and deploy automatically. Push to main, your VPS updates. No manual pipeline configuration. - **Docker-Based Deployments**: Every app runs in Docker containers with [blue-green deployment](/features/zero-downtime) for zero downtime. Automatic Dockerfile generation if you don't have one. - **Three Build Options**: Build on your VPS, build locally on your machine, or build via GitHub Actions. Choose based on your VPS specs and CI needs. - **100+ One-Click Templates**: Deploy PostgreSQL, MySQL, MongoDB, Redis, WordPress, Ghost, Supabase, n8n, Plausible Analytics, and more with a single click. Browse all [available templates](/templates). - **.env Vault**: AES-256-GCM encrypted [environment variable management](/features/env-vault). Secrets never leave your machine unencrypted. - **Database Management**: Deploy and manage databases alongside your apps with [built-in database management](/features/db-admin). Visual query editor included. - **Server Monitoring**: Real-time CPU, memory, disk, and network monitoring. Know when your server needs an upgrade before it becomes a problem. - **Domain Management**: Automatic SSL via Let's Encrypt, custom domain configuration, and DNS verification—all through the GUI. #### Pricing - **One-time license**: $29 (lifetime access, no subscriptions) - **VPS costs**: $5-50/month depending on your provider and specs - **Total monthly cost**: As low as $5/month after the one-time purchase #### Best For Developers and teams who want the closest experience to Vercel on their own infrastructure. Ideal for SaaS apps, agencies managing multiple client sites, and anyone tired of usage-based billing. The desktop app approach means no web panel to secure and no additional server resources consumed by the deployment platform itself. [See the full Server Compass vs Vercel comparison](/compare/vercel) or visit the [Vercel alternative page](/vercel-alternative) for more details. ### 2\. Coolify — The Open Source Option Coolify is a self-hosted, open-source platform that runs on your VPS and provides a web-based dashboard for deployments. It's the most popular open-source Vercel alternative with an active community. #### Key Features - **Open Source**: MIT licensed, community-driven development - **Git Integration**: GitHub, GitLab, and Bitbucket support with auto-deploy - **Database Support**: One-click PostgreSQL, MySQL, MongoDB, Redis deployment - **Automatic SSL**: Let's Encrypt integration - **Docker and Docker Compose**: Native support for containerized apps - **Team Features**: Multi-user access with role-based permissions #### Pricing - **Self-hosted**: Free (you pay for your VPS) - **Coolify Cloud**: $5/month if you don't want to self-host Coolify itself #### Considerations - **Resource overhead**: Coolify runs on your VPS, consuming RAM and CPU. Minimum 2GB RAM recommended for the platform itself. - **Self-maintenance**: You're responsible for updating Coolify and troubleshooting issues. - **Learning curve**: The web interface is comprehensive but can be overwhelming for simple deployments. #### Best For Developers who prefer open-source solutions and are comfortable with self-maintenance. Good for teams that want a web-based dashboard accessible from anywhere. [See the full Server Compass vs Coolify comparison](/compare/coolify). ### 3\. CapRover — The PaaS Builder CapRover is an open-source PaaS that you install on your VPS. It provides a web dashboard and CLI for deploying Docker-based applications. Think of it as building your own Heroku. #### Key Features - **One-Click Apps**: Large marketplace of pre-configured apps - **CLI and Web Dashboard**: Deploy via command line or browser - **Cluster Support**: Scale across multiple servers with Docker Swarm - **Automatic SSL**: Let's Encrypt wildcard certificate support - **Custom Domains**: Easy domain configuration per app #### Pricing - **Free and open source**: Apache 2.0 license - **VPS costs only**: $5-50/month depending on your needs #### Considerations - **Docker Swarm**: Uses Swarm instead of Kubernetes, which is simpler but less common in modern DevOps. - **Dated UI**: The web interface is functional but not modern. - **Limited framework detection**: Less automatic configuration compared to Server Compass or Coolify. #### Best For Developers who want a Heroku-style PaaS experience and are comfortable with Docker. Good for teams that need multi-server clustering. [See the full Server Compass vs CapRover comparison](/compare/caprover). ## Why Server Compass Is the Best Self-Hosted Vercel Alternative While Coolify and CapRover are solid options, Server Compass offers the closest experience to Vercel for several reasons: ### Feature Comparison Table Feature Vercel Server Compass Coolify CapRover Framework Detection Excellent 16+ frameworks Good Limited Git Auto-Deploy Yes Yes (GitHub Actions) Yes Yes Preview Deployments Yes Yes Yes Manual Zero-Downtime Deploy Yes Blue-green Yes Yes Automatic SSL Yes Let's Encrypt Let's Encrypt Let's Encrypt One-Click Templates Limited 100+ 50+ 100+ Database Management Vercel Postgres ($) Built-in (free) Built-in Via templates Env Variable Encryption Yes AES-256-GCM Yes Basic Server Monitoring Analytics ($) Built-in Basic Basic Resource Overhead N/A (managed) None (desktop app) 2GB+ RAM 1GB+ RAM Pricing Model Usage-based $29 one-time + VPS Free + VPS Free + VPS ### Deployment Workflow Comparison **Vercel workflow:** 1. Connect GitHub repo to Vercel 2. Vercel detects framework, configures build 3. Push to main → production deploys 4. Push to branch → preview URL generated 5. Merge PR → preview cleaned up **Server Compass workflow:** 1. Add your VPS to Server Compass (one-time setup) 2. Connect GitHub repo via the app 3. Server Compass detects framework, generates Dockerfile and GitHub Actions workflow 4. Push to main → GitHub Actions builds and deploys to your VPS 5. Push to branch → preview deployment on subdomain 6. Merge PR → preview cleaned up automatically The workflows are nearly identical. The difference is where the compute runs: on Vercel's infrastructure (usage-based billing) or your VPS (fixed monthly cost). ![Server Compass GitHub Actions integration for automated deployments](/app-screenshots/feature-github-actions.jpg) ### Cost Savings Calculator Let's calculate real savings for common scenarios: #### Scenario 1: Solo Developer with Growing SaaS Cost Category Vercel (monthly) Server Compass (monthly) Base plan $20 (Pro) $0 (one-time $29) Infrastructure Included $12 (4GB VPS) Bandwidth (500GB) $0 (under limit) Included Serverless functions (2M) $0.60 N/A (always-on) Database $20+ (Vercel Postgres) $0 (self-hosted) **Total** **$40.60/month** **$12/month** **Annual cost** **$487.20** **$144 + $29 = $173** **Annual savings** **$314.20 (65%)** #### Scenario 2: Scaling Startup (High Traffic) Cost Category Vercel (monthly) Server Compass (monthly) Base plan (3 users) $60 $0 (one-time $29) Infrastructure Included $48 (16GB VPS) Bandwidth (3TB) $800 (2TB overage) Included Serverless functions (10M) $5.40 N/A Database $50+ (scaled Postgres) $0 (self-hosted) **Total** **$915.40/month** **$48/month** **Annual cost** **$10,984.80** **$576 + $29 = $605** **Annual savings** **$10,379.80 (94%)** #### Scenario 3: Agency with 10 Client Sites Cost Category Vercel (monthly) Server Compass (monthly) Base plan $200 (10 projects x Pro) $0 (one-time $29) Infrastructure Included $24 (8GB VPS, all sites) Bandwidth $150 (combined overages) Included **Total** **$350/month** **$24/month** **Annual cost** **$4,200** **$288 + $29 = $317** **Annual savings** **$3,883 (92%)** ## Step-by-Step Migration from Vercel to Server Compass Migrating from Vercel is straightforward. Here's the complete process: ### Step 1: Provision Your VPS (10 minutes) Choose a VPS provider based on your needs: - **Hetzner**: Best value in Europe, $4-20/month for 2-8GB RAM - **DigitalOcean**: Reliable, $12-48/month for 2-8GB RAM - **Linode**: Solid performance, $12-48/month - **Vultr**: Many locations, $12-48/month Recommended specs for most apps: - 2-4 vCPUs - 4-8GB RAM - 80GB+ SSD - Ubuntu 22.04 or 24.04 ### Step 2: Install Server Compass (5 minutes) 1. Download Server Compass for your OS (Mac, Windows, or Linux) 2. Add your VPS: enter the IP address, SSH user, and SSH key 3. Server Compass connects and installs Docker, Nginx, and required dependencies automatically ### Step 3: Export Environment Variables from Vercel (5 minutes) From the Vercel dashboard: 1. Go to your project → Settings → Environment Variables 2. Copy each variable (or use the Vercel CLI: `vercel env pull .env.local`) 3. In Server Compass, go to your app → Environment → paste or import your variables Server Compass encrypts all variables with AES-256-GCM before storing them. ### Step 4: Connect Your Repository (5 minutes) 1. In Server Compass, click "New App" → "From GitHub" 2. Authorize GitHub access (OAuth) 3. Select your repository 4. Server Compass auto-detects your framework and configures the build ### Step 5: Configure Build Settings (5 minutes) Review and adjust if needed: - **Build command**: Usually auto-detected (e.g., `npm run build`) - **Output directory**: Auto-detected (e.g., `.next` for Next.js) - **Node version**: Select from the dropdown - **Build location**: VPS, local machine, or GitHub Actions For GitHub Actions builds (recommended for larger apps): 1. Server Compass generates the workflow YAML 2. Click "Push Workflow" to commit it to your repo 3. GitHub Actions will build and push to your VPS on every commit ### Step 6: Deploy and Test (10 minutes) 1. Click "Deploy" to trigger the first deployment 2. Watch the logs in real-time 3. Once complete, visit the temporary domain to verify everything works 4. Test all critical functionality ### Step 7: Configure Your Domain (10 minutes) 1. In Server Compass, go to Domains → Add Domain 2. Enter your domain name 3. Update your DNS A record to point to your VPS IP 4. Server Compass provisions the SSL certificate automatically ### Step 8: Gradual Traffic Migration (Optional) For zero-risk migration: 1. Keep Vercel running initially 2. Use Cloudflare or your DNS provider to split traffic (10% to VPS) 3. Monitor for errors and performance 4. Gradually increase to 50%, then 100% 5. Cancel Vercel subscription once confident ### Migration Checklist - VPS provisioned with recommended specs - Server Compass installed and connected to VPS - Environment variables exported from Vercel - Environment variables imported to Server Compass - GitHub repository connected - Build settings configured and tested - GitHub Actions workflow deployed (if using) - First deployment successful - All app functionality tested - Domain DNS updated - SSL certificate provisioned - Production traffic migrated - Vercel subscription cancelled ## Vercel vs Self-Hosted: Complete Comparison Aspect Vercel Self-Hosted (Server Compass) **Pricing Model** Usage-based (unpredictable) Fixed VPS cost (predictable) **Monthly Cost** $20-$2,000+ depending on traffic $5-$50 fixed **Bandwidth** 1TB included, $40/100GB after Unlimited (VPS dependent) **Build Minutes** 6,000/month, then paid Unlimited **Serverless Limits** 10-60s execution time None (always-on processes) **WebSockets** Limited/extra cost Full support **Long-Running Jobs** Not supported Full support **Database Co-location** Separate service ($) Same server (free) **Data Privacy** Vercel infrastructure Your VPS, your region **Vendor Lock-in** High (Vercel-specific features) None (standard Docker) **Global Edge** Built-in CDN Add Cloudflare (free) **Server Access** None Full root access **Maintenance** Fully managed You manage VPS (or use managed VPS) ## Real Cost Savings: Developer Stories ### Example 1: SaaS Founder Cuts $800/month A B2B SaaS with 2,000 active users was paying $850/month on Vercel: $60 for two team members, $400 in bandwidth overages (their app serves large files), $200 for Vercel Postgres, and $190 in serverless function costs. After migrating to Server Compass on a $48/month Hetzner VPS: - PostgreSQL runs on the same server - Bandwidth is unlimited - No serverless function billing (Node.js runs as always-on container) - Total: $48/month - **Savings: $802/month ($9,624/year)** ### Example 2: Agency Consolidates 15 Client Sites A digital agency was managing 15 client sites across Vercel, paying roughly $450/month total (mix of Pro plans and bandwidth overages). After migrating to Server Compass: - All 15 sites run on a single $24/month VPS - Each site gets its own Docker container - Zero-downtime deployments for each - Total: $24/month - **Savings: $426/month ($5,112/year)** ### Example 3: Indie Hacker Escapes the Hobby Tier A solo developer outgrew Vercel's hobby tier (100GB bandwidth, limited builds) and faced upgrading to Pro at $20/month with usage-based billing. Instead, they migrated to Server Compass: - $6/month VPS (Hetzner CX22) - $29 one-time license - Unlimited bandwidth and builds - Room to grow without cost anxiety - **Savings: $14/month vs Pro tier, plus predictability** ## Frequently Asked Questions ### Is self-hosting harder than using Vercel? With tools like Server Compass, the deployment experience is nearly identical to Vercel. You push to Git, your app deploys. The main difference is the initial VPS setup (10-15 minutes) and occasionally updating your server's OS (a few minutes every few months). If you can follow a tutorial, you can self-host. ### What about edge functions and global CDN? For global distribution, add Cloudflare in front of your VPS (free tier works great). You get CDN caching, DDoS protection, and edge computing via Cloudflare Workers if needed. Most apps don't need true edge computing—a well-cached CDN handles 95% of use cases. ### Can I run Next.js with all features on self-hosted? Yes. Server Compass supports Next.js fully: SSR, ISR, API routes, middleware, image optimization. The only Vercel-specific features that don't translate are Edge Runtime (use Node.js runtime instead) and Vercel Analytics (use Plausible, available as a one-click template). ### What if my VPS goes down? VPS providers offer 99.9%+ uptime SLAs, comparable to Vercel. For higher availability, deploy to two VPS instances with a load balancer (Cloudflare or your provider's). Server Compass makes multi-server deployment straightforward. ### How do I handle database backups? Server Compass includes one-click backup configuration for PostgreSQL, MySQL, and MongoDB. Backups can be stored locally or pushed to S3-compatible storage (Cloudflare R2, Backblaze B2, AWS S3). ### Is Server Compass open source? No, Server Compass is a commercial product with a one-time $29 license. If open source is a requirement, consider Coolify or CapRover, though they require more maintenance and consume VPS resources. ### Can I migrate back to Vercel if needed? Absolutely. Since Server Compass uses standard Docker containers, your app is fully portable. Reconnect your repo to Vercel and deploy—no code changes required (unless you added Vercel-specific features originally). ### How does Server Compass compare to Coolify? Server Compass is a desktop app (no server resources consumed), has better framework detection, and generates GitHub Actions pipelines. Coolify is open source, runs on your VPS, and has a web-based dashboard. Choose based on whether you prefer open source (Coolify) or lower resource usage and better DX (Server Compass). See the full [Server Compass vs Coolify comparison](/compare/coolify). ## Conclusion: Take Control of Your Deployments Vercel revolutionized web deployment, but its pricing model punishes success. A self-hosted Vercel alternative gives you the same developer experience—git-push deploys, automatic SSL, preview deployments, zero-downtime updates—without usage-based billing that scales with your traffic. **Server Compass** offers the closest experience to Vercel on your own infrastructure. With 16+ framework detection, GitHub Actions CI/CD, 100+ one-click templates, and a $29 one-time license, it's the most cost-effective path to predictable hosting costs. Whether you're a solo developer escaping the hobby tier, a startup watching every dollar, or an agency tired of per-project billing, self-hosting is the answer. Your $5-50/month VPS will handle more traffic than a $500/month Vercel bill, and you'll never worry about surprise invoices again. Ready to make the switch? [Try Server Compass today](/) and see how much you'll save. Most migrations take less than an hour, and the annual savings can be measured in thousands. ### Next Steps 1. [Read the full Vercel comparison](/compare/vercel) 2. [Visit the Vercel Alternative page](/vercel-alternative) 3. [Check pricing and download](/pricing) 4. [Watch deployment tutorials](/tutorials) --- **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. --- ## The True Cost of Heroku in 2026 (After Free Tier Removal) Source: https://servercompass.app/blog/true-cost-of-heroku-2026 Published: 2026-03-06 Tags: heroku-alternative, pricing, self-hosted, deployment, comparisons A comprehensive breakdown of Heroku pricing in 2026 after the free tier removal. Discover hidden costs, real-world examples, and why developers are migrating to self-hosted alternatives that save 80% or more. Remember when Heroku was the go-to platform for developers who wanted to deploy apps without worrying about infrastructure? Those days are gone. In November 2022, Salesforce-owned Heroku eliminated its free tier, fundamentally changing the platform's value proposition. Now in 2026, developers are left wondering: is Heroku pricing still worth it, or has the platform become too expensive for what it offers? This comprehensive guide breaks down every aspect of **Heroku pricing** in 2026—from dyno costs to add-on expenses—and shows you exactly what you'll pay for real-world applications. Spoiler alert: the numbers might shock you. ## RIP Heroku Free Tier: A Brief History For over a decade, Heroku's free tier was legendary. Developers could spin up hobby projects, prototypes, and even small production apps without paying a dime. The free dyno would sleep after 30 minutes of inactivity, but for many use cases, that was perfectly acceptable. Then came November 28, 2022. Heroku announced the end of free dynos, free Postgres databases, and free Redis instances. The reasoning? "Fraud and abuse" of free resources. But the real impact was devastating for the developer community: - Millions of hobby projects went offline overnight - Bootcamp students lost their free deployment option - Open-source maintainers scrambled for alternatives - The "Heroku is easy" recommendation became "Heroku is expensive" Fast forward to 2026, and Heroku's pricing structure has evolved—but not in favor of developers. Let's break down exactly what you'll pay. ## Current Heroku Pricing Tiers (2026) Heroku's pricing revolves around "dynos"—lightweight Linux containers that run your application code. Here's the complete breakdown: ### Eco Dynos: $5/month (The "New Free Tier") After killing the free tier, Heroku introduced Eco dynos as the entry point. At $5/month, you get: - **1000 dyno hours/month** shared across all Eco apps - **512 MB RAM** per dyno - **Sleep after 30 minutes** of inactivity (just like the old free tier) - **No horizontal scaling**—one dyno only - **No preboot** or session affinity **The catch:** 1000 hours sounds generous until you realize that running a single app 24/7 requires 720 hours/month. If you have two Eco apps, you're already over the limit. Each additional 1000 hours costs another $5. **Reality check:** Eco dynos are essentially the old free tier with a $5 paywall. The 30-minute sleep timeout means your app will have cold starts, frustrating users who hit a sleeping dyno. ### Basic Dynos: $7/dyno/month Basic dynos are the minimum for anything resembling production: - **512 MB RAM** - **No sleep timeout**—runs 24/7 - **No horizontal scaling**—still one dyno only - **No preboot** or advanced features **The problem:** With only 512 MB RAM and no scaling, Basic dynos struggle with any moderately complex application. A typical Node.js app with a few dependencies can easily hit memory limits during traffic spikes. ### Standard Dynos: $25-50/dyno/month Standard dynos are where Heroku starts getting serious—and expensive: **Standard-1X ($25/dyno/month):** - 512 MB RAM - Horizontal scaling (run multiple dynos) - Preboot for zero-downtime deploys - Session affinity available **Standard-2X ($50/dyno/month):** - 1 GB RAM - All Standard-1X features - Better suited for memory-intensive apps **The math gets ugly:** Running a production app with 3 Standard-1X dynos for redundancy costs $75/month—just for compute. Add a database, and you're already over $100/month for a simple setup. ### Performance Dynos: $250-500/dyno/month For high-traffic applications, Heroku offers Performance dynos: **Performance-M ($250/dyno/month):** - 2.5 GB RAM - Dedicated resources (no noisy neighbors) - Better CPU performance - All Standard features **Performance-L ($500/dyno/month):** - 14 GB RAM - Maximum compute performance - Ideal for memory-heavy workloads **Enterprise reality:** A production setup with 4 Performance-M dynos runs $1,000/month in dyno costs alone. Before databases. Before Redis. Before any add-ons. ## The Hidden Costs: Heroku Add-ons Dyno pricing is just the beginning. Most real applications need databases, caching, logging, and monitoring. Here's where Heroku's costs explode. ### Heroku Postgres Pricing Since killing the free tier, Heroku Postgres starts at $5/month for the most basic plan: Plan Price/Month Storage RAM Connections Essential-0 $5 1 GB Shared 20 Essential-1 $9 10 GB Shared 20 Essential-2 $15 10 GB Shared 40 Standard-0 $50 64 GB 4 GB 120 Standard-2 $200 256 GB 8 GB 400 Premium-0 $350 512 GB 30 GB 500 Premium-2 $750 1 TB 61 GB 500 **The connection trap:** Essential plans only allow 20-40 connections. A moderately busy app with connection pooling can easily exhaust these, forcing you to upgrade to Standard-0 at $50/month minimum. ### Heroku Redis Pricing Need caching or session storage? Redis pricing starts at $15/month: - **Mini ($3/month)**: 25 MB, 20 connections—basically useless - **Essential ($15/month)**: 100 MB, 40 connections - **Premium-0 ($50/month)**: 256 MB, 80 connections - **Premium-3 ($200/month)**: 1.5 GB, 200 connections - **Premium-7 ($750/month)**: 7 GB, 500 connections ### Other Essential Add-ons Most production apps need additional services: - **Papertrail (logging)**: $7-230/month depending on volume - **New Relic (monitoring)**: $25-175/month for Heroku-specific plans - **SendGrid (email)**: Free tier available, then $15-90/month - **Scheduler (cron jobs)**: Free, but consumes dyno hours - **SSL endpoints**: Now included, but custom certs cost extra ## Real-World Heroku Cost Examples Let's calculate what actual applications cost on Heroku in 2026: ### Example 1: Hobby Project / Portfolio Site A simple Node.js or Rails app with a database: - 1 Eco dyno: $5/month - Essential-0 Postgres: $5/month - **Total: $10/month ($120/year)** **The catch:** Your site sleeps after 30 minutes, taking 10-30 seconds to wake up when visitors arrive. Not exactly impressive for a portfolio. ### Example 2: Side Project That Actually Works A side project with real users that needs to stay awake: - 1 Basic dyno: $7/month - Essential-1 Postgres: $9/month - Mini Redis (sessions): $3/month - **Total: $19/month ($228/year)** **Reality:** Still limited to 512 MB RAM with no redundancy. One crash and your app is down. ### Example 3: Startup MVP (Actually Production-Ready) A real startup needs reliability and room to grow: - 2 Standard-1X dynos (redundancy): $50/month - Standard-0 Postgres: $50/month - Premium-0 Redis: $50/month - Papertrail (logging): $7/month - **Total: $157/month ($1,884/year)** **And this is minimal:** No background workers, no staging environment, basic database. Scale up just slightly and you're easily at $300-500/month. ### Example 4: Growing SaaS Application A SaaS with 1000+ users and steady traffic: - 3 Standard-2X dynos: $150/month - 2 Standard-1X worker dynos: $50/month - Standard-2 Postgres: $200/month - Premium-3 Redis: $200/month - Papertrail Pro: $45/month - New Relic APM: $75/month - **Total: $720/month ($8,640/year)** **The scale shock:** And this doesn't include staging environments (multiply by 0.5x), CI/CD pipeline costs, or any spikes in traffic that require additional dynos. ### Example 5: Enterprise Production Setup A serious production application with proper infrastructure: - 4 Performance-M dynos: $1,000/month - 2 Performance-M worker dynos: $500/month - Premium-2 Postgres: $750/month - Premium-7 Redis: $750/month - Full monitoring stack: $200/month - **Total: $3,200/month ($38,400/year)** ## Why Developers Are Leaving Heroku The free tier removal was just the catalyst. Here's why developers are migrating away from Heroku in droves: ### 1\. Terrible Price-to-Performance Ratio Compare Heroku's $25/month Standard-1X dyno (512 MB RAM, shared CPU) to a $5/month DigitalOcean droplet (1 GB RAM, 1 dedicated vCPU, 25 GB SSD). You get 2x the RAM, dedicated CPU, and persistent storage for 1/5 the price. ### 2\. Platform Stagnation Since Salesforce acquired Heroku in 2010, innovation has slowed to a crawl. While competitors ship features like edge functions, serverless containers, and integrated CI/CD, Heroku still relies on the same dyno model from 2011. ### 3\. Vendor Lock-In Heroku's Procfile-based deployment system, add-on ecosystem, and proprietary buildpacks create significant lock-in. Migrating a complex Heroku app to another platform can take weeks of engineering time. ### 4\. Limited Control You can't SSH into a dyno. You can't install custom system packages easily. You can't tune kernel parameters or optimize at the OS level. For many applications, this lack of control becomes a bottleneck. ### 5\. Reliability Concerns Heroku has experienced multiple high-profile outages in recent years. Without the ability to failover to your own infrastructure, you're entirely dependent on Heroku's operations team. ## Heroku vs. VPS: The Real Cost Comparison Let's compare the growing SaaS example ($720/month on Heroku) to self-hosting on a VPS: ### VPS Equivalent Setup - **DigitalOcean 8 GB Droplet**: $48/month (4 vCPUs, 8 GB RAM, 160 GB SSD) - **Managed Postgres (optional)**: $15/month for basic, or self-host for $0 - **Redis**: Self-hosted, $0 - **Logging/Monitoring**: Self-hosted Grafana stack, $0 - **Total: $48-63/month ($576-756/year)** **Savings: $657-672/month ($7,884-8,064/year)** That's a **91-93% cost reduction** for equivalent or better resources. ### What You Gain with Self-Hosting - **More resources**: 8 GB RAM vs. 3 GB on Heroku - **Full root access**: Install anything, tune everything - **Persistent storage**: 160 GB SSD included - **No artificial limits**: Connection counts, dyno hours, etc. - **Data sovereignty**: Choose your datacenter location - **Multiple apps**: Run unlimited applications on one server ## Better Alternatives to Heroku in 2026 If you're looking to escape Heroku's pricing, here are your best options: ### Self-Hosted PaaS Solutions Get Heroku's developer experience on your own VPS for a fraction of the cost: - **[Server Compass](/)** : Desktop app that gives you Heroku-like deployments on any VPS. One-time purchase, deploy unlimited apps. [See the full Heroku comparison](/heroku-alternative). - **Coolify**: Open-source, self-hosted Heroku alternative - **CapRover**: Free, open-source PaaS with web interface - **Dokku**: The original Heroku clone, minimal and powerful ### Managed Alternatives (If You Must) If you want managed hosting but at better prices: - **Railway**: Modern Heroku alternative with usage-based pricing - **Render**: Heroku-like experience starting at $7/month - **Fly.io**: Edge-first platform with generous free tier - **DigitalOcean App Platform**: Starts at $5/month ### Why Server Compass Wins for Heroku Refugees [Server Compass](/) specifically addresses every Heroku pain point: - **Git-push deployments**: Same workflow you're used to - **Automatic SSL**: Let's Encrypt certificates auto-renewed - **Database management**: Deploy Postgres, MySQL, MongoDB with one click - **Zero-downtime deploys**: Blue-green deployments built in - **Environment variables**: Secure vault for all your secrets - **100+ templates**: Deploy Redis, PostgreSQL, WordPress, and more instantly - **Fixed pricing**: One-time purchase, no monthly fees [See the detailed Server Compass vs. Heroku comparison](/compare/heroku) ## Quick Migration Guide: Heroku to VPS Migrating from Heroku is easier than you think. Here's the high-level process: ### Step 1: Export Your Data - `heroku pg:backups:capture` for Postgres dumps - Export environment variables with `heroku config` - Document your Procfile processes ### Step 2: Set Up Your VPS - Spin up a droplet on DigitalOcean, Hetzner, or Vultr ($5-48/month) - Install [Server Compass](/) or your preferred deployment tool - Connect your Git repository ### Step 3: Deploy Your Application - Server Compass auto-detects your framework and generates Docker configs - Import your environment variables - Deploy your Postgres database from a template - Restore your data from the Heroku backup ### Step 4: Update DNS - Point your domain to your new VPS IP - SSL certificates are automatically provisioned - Test thoroughly before decommissioning Heroku Most migrations take 2-4 hours. Your first month's savings will more than cover the time investment. ## Frequently Asked Questions ### Is there any way to use Heroku for free in 2026? No. Heroku eliminated all free options in November 2022. The cheapest option is the Eco dyno at $5/month, which still has the 30-minute sleep timeout. For truly free hosting, consider Fly.io, Render, or Railway's free tiers, or self-host on a free Oracle Cloud instance. ### What's the difference between Eco and Basic dynos? Both have 512 MB RAM, but Eco dynos sleep after 30 minutes of inactivity and share a pool of 1000 hours/month across all your Eco apps. Basic dynos run 24/7 without sleeping. For anything user-facing, Basic is the minimum viable option. ### Is Heroku still worth it in 2026? For most developers and startups, no. The convenience premium no longer justifies the 10-20x cost difference compared to VPS hosting. Heroku may still make sense for enterprises with strict compliance requirements or teams with zero DevOps capacity, but even then, managed alternatives like Railway offer better value. ### How does Heroku scaling work? You can only scale horizontally (add more dynos) with Standard or higher plans. Eco and Basic dynos are limited to one instance. Vertical scaling means upgrading to a more expensive dyno type. Both actions require manual intervention or third-party autoscaling add-ons. ### What are Heroku's hidden costs? The main hidden costs are: - **Add-on expenses**: Databases, Redis, logging, monitoring add up fast - **Staging environments**: Duplicate your entire stack for testing - **Connection limits**: Force upgrades to higher database tiers - **Build minutes**: Large apps can hit limits on lower plans - **Data transfer**: High-traffic apps may incur overage charges ### How hard is it to migrate off Heroku? Difficulty depends on your stack complexity. Simple apps (single dyno + Postgres) can migrate in a few hours. Complex setups with multiple workers, add-ons, and custom buildpacks may take 1-2 weeks. The main challenges are: - Replacing Heroku-specific add-ons with self-hosted alternatives - Converting Procfile processes to Docker containers or systemd services - Setting up CI/CD pipelines outside Heroku - Migrating environment variables and secrets ### Is managing a VPS too complex? Not anymore. Tools like [Server Compass](/) provide Heroku-level simplicity on any VPS. You get git-push deployments, automatic SSL, database management, and monitoring without touching the command line. The initial setup takes 15-30 minutes, and ongoing maintenance is minimal. ## The Bottom Line: Heroku Pricing in 2026 Heroku revolutionized deployment in 2007, but in 2026, its pricing no longer makes sense for most developers. The free tier removal was the final straw for many, and the remaining paid tiers offer poor value compared to modern alternatives. **The math is simple:** - A basic production setup on Heroku costs **$150-300/month** - The equivalent on a VPS costs **$12-48/month** - Annual savings: **$1,200-3,000+** If you're still on Heroku, it's time to evaluate your options. Whether you choose a self-hosted solution like [Server Compass](/), a managed alternative like Railway, or go full DIY with Docker on a VPS, you'll save money and gain capabilities that Heroku simply doesn't offer. Ready to escape Heroku's pricing? [See how Server Compass compares as a Heroku alternative](/heroku-alternative) , or [view the full feature comparison](/compare/heroku). --- **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. --- ## Vercel's Hidden Costs Add Up. Self-Host for $5/mo Source: https://servercompass.app/blog/vercel-pricing-explained-hidden-costs Published: 2026-03-06 Tags: vercel-alternative, pricing, self-hosted, deployment Vercel's bandwidth overages ($40/100GB), build limits, and per-seat pricing catch teams off guard. We break down every hidden cost and show how to deploy the same stack on a $5 VPS. TL;DR Vercel Pro costs **$20/seat/mo** plus bandwidth overages ($40/100GB). Server Compass lets you deploy the same Next.js stack on a **$5 VPS** with a one-time $29 payment — unlimited builds, zero bandwidth fees. [Try Server Compass free →](/) Vercel's pricing page looks simple — Hobby (free), Pro ($20/seat/mo), Enterprise (custom). What it doesn't show you: bandwidth overage at $40 per 100GB, build time limits that force upgrades, and per-seat costs that punish growing teams. A 3-person team with moderate traffic can easily spend $100+/mo on what started as a “free” deployment. But here's what most Vercel pricing breakdowns won't tell you: which costs actually matter for *your* project, and at what point self-hosting becomes the obvious choice. We dig into every line item below — including the ones Vercel buries in the fine print. Pricing verified March 2026. Vercel updates pricing frequently — check their pricing page for the latest. ## Vercel Pricing Tiers Overview Vercel offers three main pricing tiers, each designed for different scales of usage. Let's examine what you get—and what you don't—at each level. ### Hobby Tier (Free) The Hobby tier is Vercel's free plan, designed for personal projects and learning. Here's what's included: Resource Hobby Limit Bandwidth 100 GB/month Build Execution Hours 100 hours/month Serverless Function Execution 100 GB-hours/month Edge Function Execution 500,000 invocations/month Image Optimization 1,000 source images/month Concurrent Builds 1 Team Members 1 (personal only) Serverless Function Duration 10 seconds max Commercial Usage Not allowed **Key limitation:** The Hobby tier explicitly prohibits commercial usage. If you're building anything that generates revenue—a SaaS, an e-commerce site, a client project—you must upgrade to Pro. This is often the first "hidden cost" developers encounter. ### Pro Tier ($20/member/month) The Pro tier is where most serious projects land. At $20 per team member per month, it unlocks: Resource Pro Included Overage Cost Bandwidth 1 TB/month $40 per 100 GB Build Execution Hours 400 hours/month $10 per 100 hours Serverless Function Execution 1,000 GB-hours/month $0.18 per GB-hour Edge Function Execution 1,000,000 invocations $0.65 per 1M Edge Middleware Invocations 1,000,000 invocations $0.65 per 1M Image Optimization 5,000 source images $5 per 1,000 Concurrent Builds 1 (extra: $50/month) $50 per concurrent build Serverless Function Duration 60 seconds max — Preview Deployments Unlimited — Password Protection Included — **The catch:** That $20/month is per team member. A 5-person team pays $100/month before any overages. And those overages can add up fast, as we'll see. ### Enterprise Tier (Custom Pricing) Enterprise pricing is negotiated directly with Vercel's sales team. It typically includes: - Higher limits across all resources - 99.99% SLA guarantee - Dedicated support and account management - SSO/SAML authentication - Audit logs and compliance features - Custom contracts and invoicing - Serverless functions up to 900 seconds Enterprise contracts typically start at $1,500-3,000/month minimum, though this varies significantly based on usage requirements. Most startups and small teams won't need Enterprise features until they're well-established. ## Hidden Costs That Add Up The base pricing tells only part of the story. Here's where Vercel costs really start to escalate—often catching developers by surprise. ### 1\. Bandwidth Overages: $40 per 100 GB Bandwidth is often the biggest surprise on a Vercel bill. While 1 TB sounds generous, modern web applications can burn through it quickly: - A typical page load: 2-5 MB (including JavaScript bundles, images, fonts) - 1 TB = approximately 200,000-500,000 page views/month - For a growing SaaS or content site, this threshold arrives sooner than expected **Example calculation:** - Your site averages 3 MB per page view - You have 500,000 monthly page views - Total bandwidth: 1.5 TB - Overage: 500 GB = **$200/month in bandwidth fees alone** What makes this particularly painful is that you can't control when users visit your site. A viral Hacker News post or Reddit mention can spike your bandwidth—and your bill—overnight. ### 2\. Build Time Limits The Pro tier includes 400 build execution hours per month. This sounds like a lot until you consider: - A typical Next.js build: 3-10 minutes - Preview deployments on every PR push - Multiple team members pushing multiple times per day - CI/CD workflows that trigger builds on various events **Example calculation for a 5-person team:** - Average build time: 6 minutes - Each developer pushes 5 times/day - 20 working days/month - Total: 5 devs × 5 pushes × 20 days × 6 min = 3,000 minutes = 50 hours/month This seems safe, but add production deployments, hotfixes, and the occasional build that gets stuck or retried, and you can approach the limit. Exceeding it costs $10 per 100 additional hours. ### 3\. Serverless Function Execution Serverless function costs are measured in "GB-hours"—the amount of memory allocated multiplied by execution time. The Pro tier includes 1,000 GB-hours, with overages at $0.18 per GB-hour. **This gets expensive when:** - Your API routes handle heavy processing - You're doing server-side rendering on every request - Database queries take longer than expected - You have API routes that call external services with variable latency **Example:** An API route that uses 1 GB of memory and runs for 500ms costs 0.000139 GB-hours. Sounds tiny, but at 1 million requests/month, that's 139 GB-hours. Now imagine you have 10 different API routes with varying execution times across your app. ### 4\. Team Member Costs: The Per-Seat Tax At $20/member/month, team costs scale linearly. This creates a hidden tax on growth: Team Size Monthly Base Cost Annual Base Cost 1 developer $20 $240 3 developers $60 $720 5 developers $100 $1,200 10 developers $200 $2,400 20 developers $400 $4,800 And this is before any overages. A 10-person team easily spends $300-500/month when you add bandwidth and function execution costs. ### 5\. Analytics Add-on Vercel's built-in Web Analytics and Speed Insights are separate paid add-ons: - **Web Analytics:** $10/month per project (25K events/month), then $0.25 per additional 1K events - **Speed Insights:** Starts at $10/month per project For multiple projects, these costs multiply. A team with 5 production applications pays $50-100/month just for analytics—features that are often free with self-hosted alternatives like Plausible or Umami. ### 6\. Other Hidden Costs - **Concurrent Builds:** Want faster deployments with multiple builds running in parallel? That's $50/month per additional concurrent build slot. - **Cron Jobs:** Need scheduled tasks? Vercel Cron is included but execution counts against your serverless function quota. - **DDoS Protection:** Basic protection is included, but advanced features require Enterprise. - **Log Retention:** Extended log retention requires paid add-ons or third-party integrations. ## Real-World Cost Examples Let's calculate what Vercel actually costs for different scenarios. ### Scenario 1: Solo Developer with a Growing SaaS Cost Component Usage Monthly Cost Pro Plan 1 member $20 Bandwidth 800 GB (within limit) $0 Function Execution 500 GB-hours $0 Web Analytics 1 project $10 **Total** **$30/month** **Annual cost: $360**. This is Vercel's sweet spot—low traffic, one developer, minimal overages. ### Scenario 2: Small Team (5 Developers) with Moderate Traffic Cost Component Usage Monthly Cost Pro Plan 5 members $100 Bandwidth Overage 1.5 TB (500 GB over) $200 Function Execution 1,200 GB-hours $36 Extra Concurrent Build 1 slot $50 Web Analytics 2 projects $20 **Total** **$406/month** **Annual cost: $4,872**. The costs escalate quickly once you exceed included limits. ### Scenario 3: Growing Startup (10 Developers, High Traffic) Cost Component Usage Monthly Cost Pro Plan 10 members $200 Bandwidth Overage 5 TB (4 TB over) $1,600 Function Execution 3,000 GB-hours $360 Build Time Overage 200 extra hours $20 Extra Concurrent Builds 2 slots $100 Web Analytics 3 projects $30 **Total** **$2,310/month** **Annual cost: $27,720**. At this point, many teams start exploring alternatives. ## Cost Comparison: Vercel vs VPS Self-Hosting How does Vercel compare to running your own infrastructure? Let's put the numbers side by side. Scenario Vercel Monthly VPS + Server Compass Annual Savings Solo developer (low traffic) $30 $5-6 VPS + $29 one-time $289/year Small team (moderate traffic) $406 $24-48 VPS $4,296-4,584/year Growing startup (high traffic) $2,310 $96-200 VPS cluster $25,320-26,568/year **VPS providers and pricing:** - **Hetzner:** $4-6/month for 2 vCPU, 4 GB RAM, 40 GB SSD, 20 TB bandwidth - **DigitalOcean:** $12-24/month for 2-4 vCPU, 4-8 GB RAM - **Vultr:** $12-24/month for similar specs - **Linode:** $12-24/month for similar specs The key difference: VPS bandwidth is typically 1-20 TB included at no extra cost. No per-seat pricing. No serverless execution fees. Just a fixed monthly cost. ## When Vercel Makes Sense Despite the costs, Vercel is genuinely the right choice for certain situations: ### Ideal Use Cases for Vercel - **Small hobby projects:** If you're under the free tier limits and not generating revenue, Vercel is genuinely free. - **Solo developers with low traffic:** At $20-30/month, Vercel is reasonable if you value zero DevOps overhead. - **Teams that need bleeding-edge Next.js features:** Vercel often supports new Next.js features first (they build both). - **Rapid prototyping:** When speed to market matters more than optimization. - **Enterprises with budget for convenience:** If $2,000-5,000/month is inconsequential to your business, the convenience has value. - **Global edge requirements:** Vercel's edge network is genuinely excellent for globally distributed, latency-sensitive applications. ## When Self-Hosting Wins Self-hosting becomes the clear winner in these scenarios: ### Ideal Use Cases for Self-Hosting - **Teams of 3+ developers:** The per-seat pricing adds up quickly. With self-hosting, team size doesn't affect infrastructure costs. - **Moderate to high traffic sites:** Once you exceed 1 TB bandwidth regularly, VPS hosting saves hundreds monthly. - **Multiple projects:** Run unlimited projects on a single VPS. With Vercel, each project's analytics, bandwidth, and functions are metered separately. - **Long-running processes:** Need background workers, WebSockets, or processes that run longer than 60 seconds? Serverless can't help. - **Database co-location:** Running your database on the same server as your app eliminates network latency and additional managed database costs. - **Predictable budgeting:** Fixed VPS costs make financial planning easier than variable usage-based pricing. - **Data sovereignty/compliance:** Choose exactly where your data lives. - **Cost-conscious startups:** Every dollar saved extends runway. ## Alternative: Server Compass + $5 VPS If self-hosting sounds appealing but you're worried about the DevOps complexity, [Server Compass](/) bridges the gap. It provides Vercel-like developer experience on your own VPS: - **One-click Docker deployments:** Deploy Next.js, Node.js, Python, Go, and more with automatic Dockerfile generation via the [Docker Stack Wizard](/features/docker-stack-wizard) - **GitHub Actions CI/CD:** Push to GitHub, auto-deploy to your VPS with [generated GitHub Actions pipelines](/features/github-actions) - **Zero-downtime deployments:** [Blue-green deployments](/features/zero-downtime) built in - **Environment management:** Encrypted [.env vault](/features/env-vault) with AES-256-GCM encryption - **100+ templates:** Deploy databases, CMS platforms, monitoring tools, and more. [Browse templates](/templates) - **Database management:** [Built-in PostgreSQL, MySQL, MongoDB, Redis management](/features/db-admin) - **SSL/HTTPS:** Automatic Let's Encrypt certificates - **Framework detection:** Auto-detects 16+ frameworks and configures builds automatically ### Server Compass Pricing Cost Component Price Server Compass License $29 one-time (lifetime) VPS (Hetzner/DigitalOcean) $5-48/month Bandwidth Included (1-20 TB) Team Members Unlimited Projects Unlimited **Total cost for most teams:** $5-48/month + $29 one-time. Compare that to $406/month for a 5-person team on Vercel Pro. For a detailed comparison, see our [Server Compass vs Vercel comparison](/compare/vercel) or explore the [Vercel alternative](/vercel-alternative) page. ## Quick Vercel Cost Calculator Use this simple formula to estimate your Vercel costs: `Monthly Vercel Cost = (Team Members × $20) + (Bandwidth over 1TB in 100GB chunks × $40) + (Function GB-hours over 1000 × $0.18) + (Build hours over 400 in 100hr chunks × $10) + (Extra concurrent builds × $50) + (Projects with Analytics × $10)` **Example for a 5-person team with 2TB bandwidth and 1,500 GB-hours functions:** `= (5 × $20) + (10 × $40) + (500 × $0.18) + $0 + $0 + $10 = $100 + $400 + $90 + $10 = $600/month or $7,200/year` ## Migration Guide: Vercel to Self-Hosted Ready to make the switch? Here's a brief migration roadmap: ### Migration Steps 1. **Provision a VPS:** Start with a $12-24/month droplet on DigitalOcean, Hetzner, or Vultr. 4 GB RAM handles most applications comfortably. 2. **Install Server Compass:** Download the desktop app for Mac, Windows, or Linux. Connect to your VPS via SSH. 3. **Connect your repository:** Link your GitHub account. Server Compass auto-detects your framework and generates a Dockerfile. 4. **Migrate environment variables:** Export from Vercel, import into Server Compass's encrypted .env vault. 5. **Deploy:** Push to GitHub or trigger a manual deploy. Server Compass handles Docker builds, container orchestration, and SSL. 6. **Update DNS:** Point your domain's A record to your VPS IP. SSL certificates are provisioned automatically. 7. **Monitor and optimize:** Use Server Compass's built-in monitoring to track CPU, memory, and disk usage. Most migrations complete in 1-2 hours. The investment pays for itself within the first month for most teams. ## Frequently Asked Questions ### Is Vercel's free tier enough for a production app? No. The Hobby tier explicitly prohibits commercial use. Any revenue-generating application—including displaying ads—requires the Pro tier at minimum. Additionally, the 100 GB bandwidth limit is easily exceeded by moderately trafficked sites. ### How do I know how much bandwidth I'm using? Vercel shows bandwidth usage in your project dashboard under Analytics → Usage. As a rough estimate: page size in MB × monthly page views = bandwidth in MB. A 3 MB page with 100,000 views/month = 300 GB. ### Can I reduce Vercel costs without leaving? Yes, some strategies help: - Use Cloudflare in front of Vercel to cache static assets and reduce bandwidth - Optimize images with external services like Cloudinary or imgix - Implement aggressive caching headers - Use Static Generation (SSG) instead of Server-Side Rendering (SSR) where possible - Reduce serverless function execution time by optimizing database queries However, these optimizations have limits. Usage-based pricing fundamentally scales with success. ### Can I run Next.js without Vercel? Absolutely. Next.js is an open-source framework that runs anywhere Node.js runs. You can deploy Next.js to any VPS, cloud provider, or container platform. Server Compass auto-detects Next.js projects and generates optimized Dockerfiles for production deployment. ### What are the downsides of self-hosting? Self-hosting requires: - Basic server maintenance (OS updates, monitoring) - Setting up your own global CDN if you need edge caching (Cloudflare is free) - More initial setup time (though tools like Server Compass minimize this) - Taking responsibility for security and backups For many teams, these tradeoffs are worth the 80-95% cost savings. ### How does Vercel pricing compare to Netlify? Netlify Pro is also per-seat ($19/member/month) with similar overage structures. Bandwidth overages are $55/100 GB on Netlify vs $40/100 GB on Vercel. Both platforms become expensive at scale. For a detailed comparison of all options, see our [Top 7 Vercel Alternatives](/blog/top-7-vercel-alternatives-for-developers-in-2025) guide. ### Is Vercel Enterprise worth it? Enterprise makes sense if you need SLAs, compliance certifications, SSO, or dedicated support. The typical minimum commitment of $1,500-3,000/month is only justifiable for larger organizations where downtime costs exceed that amount. Most startups and small teams don't need Enterprise features. ## Conclusion: Understanding Your True Costs Vercel pricing seems simple on the surface—$20/member/month for Pro—but the reality is more complex. Bandwidth overages, serverless function execution, build times, and per-seat pricing combine to create bills that often shock growing teams. **The key insight:** Vercel's pricing model rewards low usage and punishes success. The more your application grows, the more you pay—often disproportionately to the actual infrastructure cost. For solo developers with small projects, Vercel remains convenient and reasonably priced. For teams of 3+ with growing traffic, the math shifts dramatically in favor of self-hosting. A $24/month VPS with [Server Compass](/) ($29 one-time) gives you: - Unlimited team members - Unlimited bandwidth (up to your VPS allocation) - Unlimited function execution time - Unlimited projects on a single server - Full control over your infrastructure - No surprise bills The savings for a typical 5-person team: **$4,000-5,000 annually**. Ready to take control of your infrastructure costs? [Try Server Compass](/) and deploy to your own VPS in minutes. Your finance team will thank you. ### Related Resources - [Server Compass vs Vercel: Full Comparison](/compare/vercel) - [Vercel Alternative: Why Developers Are Switching](/vercel-alternative) - [Top 7 Vercel Alternatives for Developers in 2025](/blog/top-7-vercel-alternatives-for-developers-in-2025) - [Server Compass vs Vercel: Save Thousands Annually](/blog/server-compass-vs-vercel-take-control-of-your-infrastructure-and-save-thousands) - [Why Self-Hosting Is the Smartest Move for Developers](/blog/why-self-hosting-is-the-smartest-move-for-developers) --- **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. --- ## Why Self-Hosting Saves Developers $600+ Per Year Source: https://servercompass.app/blog/why-self-hosting-saves-developers-600-per-year Published: 2026-03-06 Tags: self-hosted, pricing, vercel-alternative, vps-deploy, cost-savings Break down the real costs of PaaS platforms like Vercel, Railway, Heroku, and Netlify. See how a $5/month VPS can replace $50+/month in managed hosting fees, with a complete cost comparison calculator and getting started guide. If you're a developer in 2026, there's a good chance you're paying for at least one Platform-as-a-Service (PaaS) provider. Vercel for your Next.js apps. Railway for your backend services. Maybe Heroku for that legacy project or Netlify for static sites. These platforms are convenient, polished, and incredibly easy to use. They're also quietly draining your bank account. The dirty secret of modern PaaS platforms is that their pricing models are designed to seem cheap at first and scale aggressively as your usage grows. What starts as a “free tier” or “just $20/month” quickly balloons into hundreds of dollars annually — often for workloads that could run on a $5/month VPS. In this comprehensive guide, we'll break down the real costs of popular PaaS platforms, show you what you're actually paying for, and demonstrate how **self hosting cost savings** can put $600 or more back in your pocket every year. We'll include a real savings calculator, cost comparison tables, and a step-by-step guide to getting started. ## The Hidden Costs of PaaS Platforms PaaS platforms have mastered the art of incremental pricing. The base plan looks reasonable, but the real costs hide in the details: bandwidth overages, build minutes, serverless function invocations, team seats, and “add-ons” that should be standard features. Let's examine what developers actually pay across the major platforms. ## Common PaaS Costs Breakdown ### Vercel: $240+/Year for Pro Vercel is the darling of the Next.js ecosystem, and for good reason — the developer experience is excellent. But that experience comes at a premium. **Vercel Pro Pricing (per team member):** - **Base cost:** $20/month = **$240/year** minimum - **Bandwidth:** 1TB included, then $40 per 100GB overage - **Serverless function execution:** 1M included, then $0.60 per additional million - **Build minutes:** 6,000/month included, then $0.025/minute overage - **Edge Middleware invocations:** 1M included, then $2 per million - **Image optimization:** 5,000 source images, then $5 per 1,000 **Real-world scenario:** A moderately successful SaaS with 10,000 monthly active users can easily hit 2TB of bandwidth and 5M function executions. That's $20 (base) + $400 (bandwidth overage) + $2.40 (functions) = **$422.40/month or $5,069/year**. Even staying within limits, the $240/year baseline is just the starting point. Add a second team member and you're at $480/year. Three team members? $720/year. For hosting what could be a single Docker container. For a deep dive into Vercel's pricing structure, see our [Vercel Pricing Explained: Hidden Costs Revealed](/blog/vercel-pricing-explained-hidden-costs) guide. ### Railway: Usage Adds Up Fast Railway markets itself as a simple, usage-based platform. Pay for what you use. Sounds fair, right? Until you realize how quickly “what you use” accumulates. **Railway Pricing:** - **Hobby plan:** $5/month credit included - **Pro plan:** $20/month per seat + usage - **vCPU:** $0.000231/minute (~$10/month for 1 vCPU 24/7) - **Memory:** $0.000231/GB/minute (~$10/month for 1GB RAM 24/7) - **Network egress:** $0.10/GB - **Disk storage:** $0.25/GB/month **Real-world scenario:** A typical Node.js API server with a PostgreSQL database: - API server: 0.5 vCPU + 512MB RAM = ~$7.50/month - PostgreSQL: 0.5 vCPU + 1GB RAM + 10GB disk = ~$12.50/month - Network: 50GB egress = $5/month - **Total:** ~$25/month or **$300/year** Add a Redis cache, a background worker, and staging environments, and you're looking at $50-100/month or **$600-1,200/year** for infrastructure that fits on a single $10/month VPS. ### Heroku: $84+/Year Minimum Heroku pioneered the modern PaaS model, but its pricing hasn't aged well. After eliminating their free tier in 2022, even hobby projects require payment. **Heroku Pricing:** - **Eco dynos:** $5/month (sleeps after 30 minutes of inactivity) - **Basic dynos:** $7/month (always on, but limited resources) - **Standard-1X:** $25/month (512MB RAM) - **Standard-2X:** $50/month (1GB RAM) - **Heroku Postgres Mini:** $5/month (10K rows limit) - **Heroku Postgres Basic:** $9/month (10M rows, no fork/follow) - **Heroku Postgres Standard:** $50/month+ (production-ready) - **Heroku Redis Mini:** $3/month - **Heroku Redis Premium:** $15/month+ **Real-world scenario:** A minimal production app with one always-on dyno and a basic database: - Basic dyno: $7/month - Postgres Basic: $9/month - **Total:** $16/month or **$192/year** Need more RAM, a Redis cache, or multiple workers? You're quickly at $50-100/month or **$600-1,200/year**. ### Netlify: $348+/Year for Teams Netlify excels at static sites and Jamstack deployments, but their pricing for anything beyond hobby use is steep. **Netlify Pricing:** - **Pro plan:** $19/month per member = **$228/year** minimum - **Bandwidth:** 1TB included, then $55 per 100GB - **Build minutes:** 25,000/month, then $7 per 500 minutes - **Serverless functions:** 125K/month, then $25+ per 2M - **Forms:** 100 submissions/month on Pro, then $19/month extra - **Identity (auth):** 1,000 active users, then $99/month for 10K **Real-world scenario:** A team of two running a SaaS with authentication: - Pro plan (2 seats): $38/month - Identity add-on: $99/month (for 10K users) - Form submissions: $19/month - **Total:** $156/month or **$1,872/year** Even a single developer on Pro paying just the base rate is at **$228/year** for what's essentially static file hosting with some serverless sprinkles. ## VPS Cost Reality: What You Actually Need Now let's look at what a VPS actually costs. These are real prices from major providers as of 2026: ### Budget VPS Options Provider Plan Specs Monthly Yearly DigitalOcean Basic Droplet 1 vCPU, 1GB RAM, 25GB SSD, 1TB transfer $6 **$72** Hetzner CX22 2 vCPU, 4GB RAM, 40GB SSD, 20TB transfer $4.35 **$52** Vultr Cloud Compute 1 vCPU, 1GB RAM, 25GB SSD, 1TB transfer $5 **$60** Linode Nanode 1 vCPU, 1GB RAM, 25GB SSD, 1TB transfer $5 **$60** **The $5/month Droplet or Hetzner server can run:** - Multiple web applications (Next.js, Django, Laravel, etc.) - PostgreSQL or MySQL database - Redis for caching - Background job workers - Monitoring tools (Uptime Kuma, Grafana) - Automatic SSL via Let's Encrypt - Unlimited deployments - Unlimited bandwidth (within reason) That's a complete production stack for **$60/year**. Compare that to the $300-1,200/year you'd pay on PaaS platforms for equivalent workloads. ### Higher-Resource VPS Options Need more power? VPS pricing scales linearly, unlike PaaS platforms where costs can explode unexpectedly: Provider Specs Monthly Yearly Hetzner CX32 4 vCPU, 8GB RAM, 80GB SSD $7.50 **$90** DigitalOcean 4 vCPU, 8GB RAM, 160GB SSD $48 **$576** Hetzner CX42 8 vCPU, 16GB RAM, 160GB SSD $15 **$180** Even a beefy 8 vCPU/16GB RAM server from Hetzner costs just $180/year. That's less than a single Vercel Pro seat for an entire year. ![Server Compass dashboard showing multiple Docker containers running on a single VPS with CPU and memory monitoring](/app-screenshots/feature-container-status.jpg) ## Real Savings Calculator Let's calculate the actual savings for common scenarios. These numbers assume you're moving from a PaaS to a self-hosted VPS. ### Scenario 1: Solo Developer with Side Projects Platform Monthly Cost Yearly Cost Vercel Pro (1 seat) $20 $240 Railway (hobby usage) $15 $180 **PaaS Total** **$35** **$420** Hetzner VPS (CX22) $4.35 $52 **Annual Savings** **$368/year** ### Scenario 2: Small SaaS (One Product) Platform Monthly Cost Yearly Cost Vercel Pro (2 seats) $40 $480 Railway (API + DB + Redis) $35 $420 **PaaS Total** **$75** **$900** DigitalOcean Droplet (4GB) $24 $288 **Annual Savings** **$612/year** ### Scenario 3: Agency with Multiple Clients Platform Monthly Cost Yearly Cost Vercel Pro (3 seats) $60 $720 10 client sites on Netlify $190 $2,280 **PaaS Total** **$250** **$3,000** 2x Hetzner VPS (CX32) $15 $180 **Annual Savings** **$2,820/year** For agencies, the savings are dramatic. Instead of paying per-site or per-seat, you pay for raw compute. A single VPS can host 10+ client sites, and you can scale by adding more servers as needed. ## What You Get with Self-Hosting Beyond the cost savings, self-hosting gives you capabilities that PaaS platforms either don't offer or charge extra for: ### Unlimited Deployments PaaS platforms count your builds. Self-hosting? Deploy as many times as you want. Run continuous deployment on every commit. No build minute limits, no throttling. ### Predictable Costs Your VPS costs the same every month. No surprise bills from traffic spikes. No bandwidth overages. Your server handles the load or you upgrade — your choice, your timeline. ### Full Control Over Your Stack - Install any software or service - Run long-running processes and cron jobs - Configure your database exactly how you want - Use any version of Node.js, Python, Go, or Rust - Set up custom caching layers - Run multiple apps on one server ### Data Privacy and Compliance Your data stays on your server. No third-party has access to your database, logs, or environment variables. This simplifies GDPR compliance and client trust for agencies. ### No Cold Starts Your applications are always running. No serverless cold starts adding 500ms-2s to requests. Consistent, fast response times for your users. ### No Vendor Lock-In Standard Docker containers run anywhere. Not happy with your VPS provider? Migrate in hours, not weeks. Your deployment isn't tied to proprietary Edge Functions or platform-specific APIs. ## The “Complexity” Myth: It's Easier Than You Think The most common objection to self-hosting: “But it's so complicated!” This was true in 2015. It's not true in 2026. Modern deployment tools have eliminated the DevOps knowledge gap. You don't need to know how to configure Nginx by hand. You don't need to write Dockerfiles from scratch. You don't need to set up SSL certificates manually. ### What Used to Be Required - SSH into your server and run manual commands - Configure Nginx or Apache virtual hosts - Set up SSL with certbot - Write Docker Compose files - Build CI/CD pipelines from scratch - Configure firewalls and fail2ban - Set up monitoring and alerting ### What Modern Tools Provide - Visual interfaces for server management - One-click app deployments - Automatic SSL certificate provisioning - Auto-generated Dockerfiles based on your framework - Built-in CI/CD from GitHub - Security hardening with a single toggle - Pre-configured monitoring dashboards The learning curve has collapsed. What took a dedicated DevOps engineer in 2015 now takes any developer 30 minutes to set up. ![Server Compass framework detection showing automatic Dockerfile generation for Next.js projects](/app-screenshots/feature-framework-detect.jpg) ## Tools That Make Self-Hosting Easy Several tools have emerged to give you PaaS-level convenience on your own VPS: ### Server Compass [Server Compass](/) is a desktop app that turns any VPS into a deployment platform. Key features: - **Framework detection:** Automatically detects 16+ frameworks and generates optimized Dockerfiles - **One-click templates:** Deploy 166+ applications (databases, CMS, tools) instantly - **Zero-downtime deployments:** Blue-green deployments built in - **GitHub integration:** Connect your repo, auto-deploy on push - **Automatic SSL:** Let's Encrypt certificates for every domain - **Security tools:** Firewall management, fail2ban, SSH hardening - **No server agent:** Connects via SSH only when needed Server Compass costs [$29 one-time](/pricing) — not a subscription. Deploy unlimited apps to unlimited servers forever. ### Other Self-Hosting Tools - **Coolify:** Open-source, self-hosted. Requires installation on your VPS. Good for single-server setups. - **CapRover:** Open-source PaaS you install on your server. Docker-based with a web UI. - **Dokku:** Heroku-style git push deployments. Command-line focused. For a detailed comparison, see our guide to the [Best Self-Hosted Deployment Platforms in 2026](/blog/best-self-hosted-deployment-platforms-2026) . ## Cost Comparison Table: 1 Year vs 3 Years Let's put all the numbers together. This table compares the total cost of ownership for a typical small SaaS (frontend + API + database + Redis): ### 1-Year Cost Comparison Solution Year 1 Cost Includes Vercel + Railway + managed Redis $720 Frontend hosting, API, DB, cache Heroku (Standard-1X + Postgres + Redis) $840 1 dyno, basic DB, mini Redis Render (Starter + DB + Redis) $504 Web service, Postgres, Redis Netlify Pro + external backend $600+ Frontend only, backend extra **VPS + Server Compass** **$89** $60 VPS + $29 tool (one-time) ### 3-Year Cost Comparison Solution Year 1 Year 2 Year 3 3-Year Total Vercel + Railway $720 $720 $720 **$2,160** Heroku $840 $840 $840 **$2,520** Render $504 $504 $504 **$1,512** **VPS + Server Compass** $89 $60 $60 **$209** **Over 3 years, self-hosting saves $1,300 to $2,300** compared to PaaS platforms. The savings only compound over time because your VPS cost stays flat while you 've already paid for your deployment tool. ## Getting Started: Your First Self-Hosted Deployment Ready to make the switch? Here's a step-by-step guide to deploying your first application on your own VPS: ### Step 1: Get a VPS (5 minutes) Sign up for a VPS provider. We recommend: - **Hetzner** (best value, EU servers): 4GB RAM for $4.35/month - **DigitalOcean** (great UI, US/EU/Asia): 1GB RAM for $6/month - **Vultr** (global locations): 1GB RAM for $5/month Choose Ubuntu 22.04 or 24.04 LTS as your OS. Note down your server's IP address and root password. ### Step 2: Set Up Your Deployment Tool (5 minutes) Download [Server Compass](/) for Mac, Windows, or Linux. Launch the app and add your server by entering the IP address and credentials. Server Compass will automatically: - Set up SSH key authentication - Install Docker and required dependencies - Configure automatic security updates - Set up the firewall with sensible defaults ### Step 3: Connect Your GitHub Repository (2 minutes) Authenticate with GitHub OAuth and select the repository you want to deploy. Server Compass will analyze your project and detect the framework automatically. ### Step 4: Deploy (3 minutes) Click deploy. Server Compass will: - Generate an optimized Dockerfile for your framework - Build your application - Deploy with zero-downtime (blue-green) - Set up SSL automatically - Configure your domain Your app is now live on your own server. Total time: about 15 minutes. ### Step 5: Add a Database (Optional, 1 minute) Need PostgreSQL, MySQL, or Redis? Go to the Templates section and click deploy. Your database will be running alongside your app in seconds, with connection strings automatically available. ![Server Compass template gallery showing 166+ one-click deployment options for databases and applications](/app-screenshots/feature-templates.jpg) ## When PaaS Still Makes Sense Self-hosting isn't for everyone. PaaS platforms still make sense when: - **You need global edge distribution:** Vercel's Edge Network is genuinely excellent for latency-critical applications. - **You're truly serverless:** Sporadic workloads with long idle periods can be cheaper on serverless platforms. - **You need enterprise support:** Large organizations with SLAs and compliance requirements may need vendor support. - **You're under free tier limits:** If you genuinely fit in free tiers, there's no reason to change. But if you're paying $50+/month for any PaaS platform, you should seriously consider the self-hosted alternative. ## Frequently Asked Questions ### Is self-hosting hard to maintain? Not anymore. Modern tools handle updates, SSL renewals, and security patches automatically. With Server Compass, your server maintenance is a few clicks per month, not hours of terminal work. ### What about security? Am I responsible now? You're responsible, but modern tools make it easy. Server Compass includes automatic SSL, firewall configuration, fail2ban setup, and SSH hardening. You get enterprise-grade security without the expertise requirement. ### Can I scale if my app goes viral? Absolutely. Vertical scaling (upgrading your VPS) takes minutes. Horizontal scaling (adding more servers) works the same way — add a new VPS and deploy. Unlike PaaS platforms where viral traffic means viral bills, your VPS costs stay predictable. ### What if my server goes down? Major VPS providers (DigitalOcean, Hetzner, Vultr) have 99.99% uptime SLAs. For critical applications, you can run multiple servers behind a load balancer, or use managed database services while self-hosting the application layer. ### How hard is it to migrate from Vercel/Railway/Heroku? Surprisingly easy. Your code doesn't change — only where it runs. Most migrations take 1-2 hours. See our [Vercel alternative](/vercel-alternative) guide for detailed migration steps. ### Is the $600+/year savings worth the setup time? Let's do the math. Setup takes about 2 hours. If you save $600/year, that's effectively $300/hour for your time. Over 3 years, you save $1,500-2,500 for 2 hours of initial work. Yes, it's worth it. ## Conclusion: Take Control of Your Hosting Costs The PaaS convenience tax is real. Every month, developers collectively pay millions of dollars for infrastructure that could run on commodity VPS servers at a fraction of the cost. Self-hosting in 2026 is not the nightmare it was a decade ago. The tools have caught up. The complexity has been abstracted away. What remains is a simple value proposition: pay $60/year for a VPS instead of $600+/year for managed platforms. The **self hosting cost savings** are undeniable: - $368-612/year for solo developers - $600-1,200/year for small SaaS companies - $2,000-5,000/year for agencies That's real money that could go toward marketing, hiring, or extending your runway. Ready to stop paying the PaaS tax? [Try Server Compass](/) — $29 one-time, no subscription. Deploy unlimited apps to unlimited servers on your own infrastructure. Your server, your rules, your savings. [View pricing](/pricing) | [Compare to Vercel](/vercel-alternative) | [Browse 166+ templates](/templates) --- **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. --- ## Beginner's Guide: Host Multiple WordPress Sites on One Server - No Terminal Required Source: https://servercompass.app/blog/beginner-host-multiple-wordpress-sites-no-terminal Published: 2026-03-05 Tags: wordpress, docker, ssl, lets-encrypt, traefik, self-hosted, tutorials A beginner's guide to deploying multiple WordPress sites on a Hetzner Cloud server with automatic SSL certificates using a visual interface. Running multiple WordPress websites typically requires either expensive managed hosting ($15-30/month per site) or complex server administration with terminal commands, nginx configuration, and manual SSL certificate management. For beginners, freelancers, and small agencies, these costs and complexity add up quickly. **The good news:** You don't need to be a server expert to host your own WordPress sites anymore. This tutorial walks you through setting up multiple WordPress sites on a single Hetzner Cloud server — step by step, with screenshots. We'll use Server Compass, a desktop app that lets you manage servers visually without typing commands. Each WordPress site runs in its own isolated container with a dedicated database, and SSL certificates are obtained automatically. **What you'll achieve:** - 3+ WordPress sites running on a single €4.35/month Hetzner Cloud server (CX12) - Automatic HTTPS with Let's Encrypt certificates (auto-renewed) - Isolated environments (one site can't affect another) - Visual management — click buttons instead of typing commands - Secure SSH key authentication - Easy backups and updates **Architecture overview:** ``` +-------------------------------------------+ | Hetzner Cloud VPS | | +--------------------------------------+ | | | Traefik (Reverse Proxy) | | | | - Routes by domain name | | | | - Auto SSL via Let's Encrypt | | | +----------+-----------+--------------+ | | | | | | +------+---+ +---+-------+ | | | WordPress| | WordPress | ... | | | Site A | | Site B | | | | + MySQL | | + MySQL | | | +----------+ +----------+ | +-------------------------------------------+ ``` ## Prerequisites - A computer running macOS, Windows, or Linux - A Hetzner Cloud account ( [sign up here](https://console.hetzner.cloud/) ) - One or more domain names you control (we'll show you how to configure DNS) **No prior experience required** — this tutorial explains everything from the beginning, including how to set up SSH keys and connect to servers. **Example terminology** This tutorial uses example values that you should replace with your own: Placeholder Example Description `` `203.0.113.10` Your Hetzner server's public IP `` `example.com` Your domain name `` `Kx7mP9qR2sT4vW6y` Generated database password ## Step 1 - Create SSH Key, Server, and Connect In this step, we'll set up everything you need: Server Compass on your computer, an SSH key for secure access, a Hetzner cloud server, and connect them together. ### Step 1.1 - Download and install Server Compass 1. Download Server Compass from [servercompass.app](/) 2. Install it on your computer (available for macOS, Windows, and Linux) 3. Open the application ### Step 1.2 - Create your SSH key An SSH key is like a secure password that your computer uses to connect to servers. Server Compass makes creating one easy. 1. In Server Compass, click **"SSH Keys"** in the left sidebar 2. Click **"+ Generate New Key"** in the top right ![Generate SSH key in Server Compass](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/1-generate-ssh-key.jpg) 3. Enter a name for your key (e.g., `wordpress-vps`) 4. Click **"Generate Key Pair"** ![Name your SSH key](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/2-name-your-ssh-key.jpg) 5. Find your new key in the list and click **"Public Key"** to copy it to your clipboard ![Copy public key in Server Compass](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/4-how-to-copy-publickey-in-server-compass.jpg) Server Compass generates a key pair and saves it securely on your computer. Keep Server Compass open — you'll need it again soon. ### Step 1.3 - Sign up for Hetzner Cloud If you don't already have an account: 1. Go to [console.hetzner.cloud](https://console.hetzner.cloud/) 2. Click **"Register"** and create your account 3. Complete the verification process ### Step 1.4 - Choose your server size The server size depends on how many WordPress sites you plan to host: Sites Server Type RAM Monthly Cost 1-3 CX12 4 GB €4.35 4-7 CX32 8 GB €7.59 8-12 CX42 16 GB €14.64 For this tutorial, we'll use CX12 which is perfect for getting started. ### Step 1.5 - Create the server with your SSH key 1. Log into the [Hetzner Cloud Console](https://console.hetzner.cloud/) 2. Select your project (or create a new one by clicking **"+ New Project"**) 3. Click **"Add Server"** 4. Configure with these settings: Setting Value Location Choose closest to your users (e.g., Falkenstein for Europe) Image Ubuntu 24.04 Type CX12 (or higher based on site count) Networking Public IPv4 (enabled) 1. In the **SSH Keys** section, click **"+ Add SSH key"** ![Add SSH key button in Hetzner](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/3-add-ssh-key-in-hetzer.jpg) 1. Paste the public key you copied from Server Compass into the **SSH key** field 2. Enter a name (e.g., `wordpress-vps`) 3. Click **"Add SSH key"** ![Paste public key in Hetzner](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/5-paste-key-in-hetzer.jpg) 1. Set the server name to `wordpress-production` 2. Click **"Create & Buy Now"** Your server will be ready in about 30 seconds. **Important:** Note the **IPv4 address** displayed — you'll need this in the next step. **Screenshot suggestion:** Hetzner Cloud Console showing the newly created server with IP address highlighted ### Step 1.6 - Connect Server Compass to your server 1. In Server Compass, click **"Add Server"** ![Click Add Server button in Server Compass](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/6-add-server-button-press.jpg) 1. Fill in your server details: Field Value Display Name Hetzner Production (or any name you prefer) Server IP / Hostname Your server's IPv4 address from Step 1.5 Username root Port 22 1. Under **"Choose your authentication method"**, select **SSH Key** 2. Select the key you created in Step 1.2 from the dropdown ![Fill in server details and select SSH key](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/7-connect-server-fill-in-fields.jpg) 1. Click **"Test & Connect"** Server Compass will establish a secure connection using your SSH key — no password needed. ### Step 1.7 - Install Docker and Traefik When connecting to a fresh server, Server Compass detects that Docker isn't installed and prompts you to set up the required infrastructure. **Screenshot suggestion:** Server Compass installation prompt showing Docker and Traefik 1. Server Compass shows: **"This server needs Docker and Traefik to run applications"** 2. Click **"Install"** 3. Watch the progress in the logs panel (takes 1-2 minutes) **What's being installed:** Component Purpose Docker Engine Runs your WordPress sites in isolated containers Docker Compose Manages multiple containers together Traefik Routes traffic to the right site and handles SSL certificates Once complete, you'll see a success message and your server is ready for deployments. **Screenshot suggestion:** Server Compass dashboard showing connected server with green status ## Step 2 - Create Your WordPress App Now for the exciting part — deploying your first WordPress site. Server Compass makes this simple with a built-in WordPress template. ### Step 2.1 - Create the WordPress app 1. In Server Compass, click on your server to open its detail page 2. Click the **"Apps"** tab 3. Click **"+ New App"** in the top right ![Click New App](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/1-add-new-app.jpg) 1. Select **"App Template"** to deploy from a curated template ![Select App Template](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/2-select-template.jpg) 1. Search for **"wordpress"** in the search box 2. Select the **WordPress** template (WordPress CMS with MySQL database) 3. Click **"Next"** ![Search for WordPress template](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/3-search-for-wordpress-template.jpg) 1. Enter your **Project Name** (e.g., `wordpress`) 2. The **Port** will be auto-assigned (default 3000) — you can keep the default 3. Click **"Next"** ![Fill in app name and port](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/4-fill-appname-name-port.jpg) 1. Review the **Environment Variables** — you can customize or use the defaults: Variable Description DB\_NAME WordPress database name DB\_USER WordPress database user DB\_PASSWORD Database password (click "Generate Password") DB\_ROOT\_PASSWORD MySQL root password (click "Generate Password") ![Configure environment variables](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/5-configure-env-like-dbname-password-or-use-default.jpg) 1. Click **"Deploy"** to start the deployment ### Step 2.2 - Watch the deployment progress Server Compass shows you exactly what's happening in real-time: ![Deployment progress](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/6-deployment-progress-loading.jpg) The deployment goes through these steps: 1. **Preparing** — Setting up deployment environment 2. **Pulling Images** — Downloads WordPress and MySQL containers 3. **Building** — Configures the application 4. **Starting** — Launches the containers 5. **Verifying** — Confirms everything is running The entire process takes 1-3 minutes. You can close this window — Server Compass will notify you when it's done. Once complete, you'll see your WordPress app with a green **"Running"** status: ![Deployment success](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/7-success-and-open-app.jpg) Your WordPress app is now running. But before you can access it with a domain, you need to configure DNS (Step 3). **What's happening behind the scenes** Server Compass creates a clean folder structure on your server. If you're curious, you can explore it via the Terminal tab: ``` root@demo-vps:~# ls server-compass root@demo-vps:~# cd server-compass/apps/ root@demo-vps:~/server-compass/apps# ls second-wordpress wordpress wordpress-site3 ``` Each app has its own folder with a `docker-compose.yml` file that Server Compass manages: ``` root@demo-vps:~/server-compass/apps/wordpress# cat docker-compose.yml ``` ``` {`services: wordpress: image: wordpress:latest ports: - 3000:80 environment: - WORDPRESS_DB_HOST=db:3306 - WORDPRESS_DB_USER=wordpress - WORDPRESS_DB_PASSWORD=Dm8LFDuYsKoQ63ENvLByD4gE - WORDPRESS_DB_NAME=wordpress volumes: - wordpress_data:/var/www/html restart: unless-stopped depends_on: db: condition: service_healthy labels: - traefik.enable=true - traefik.http.routers.yourdomain-com.rule=Host(\`yourdomain.com\`) - traefik.http.routers.yourdomain-com.entrypoints=websecure - traefik.http.routers.yourdomain-com.tls.certresolver=letsencrypt # ... more Traefik labels for HTTPS and www redirect networks: - default - traefik-public db: image: mysql:8.0 environment: - MYSQL_DATABASE=wordpress - MYSQL_USER=wordpress - MYSQL_PASSWORD=Dm8LFDuYsKoQ63ENvLByD4gE - MYSQL_ROOT_PASSWORD=9QHmK4mGoIJb6etmF9dk0xVo volumes: - db_data:/var/lib/mysql restart: unless-stopped healthcheck: test: ["CMD-SHELL", "mysqladmin ping -h localhost"] interval: 10s timeout: 5s retries: 5 volumes: wordpress_data: db_data: networks: traefik-public: external: true`} ``` **Key things Server Compass handles for you:** Feature How it works **SSL Certificates** Traefik labels automatically request Let's Encrypt certificates **HTTPS Redirect** HTTP requests are redirected to HTTPS **WWW Redirect** `www.yourdomain.com` redirects to `yourdomain.com` **Database Health** MySQL waits until healthy before WordPress starts **Persistent Data** Docker volumes keep your data safe across restarts You don't need to edit these files — Server Compass manages everything. But it's helpful to understand what's running on your server. ### Step 2.3 - Complete the WordPress setup wizard After connecting your domain (Step 3), click **"Open"** to visit your WordPress site: 1. You should see a green padlock (HTTPS is working) and the WordPress installation wizard 2. Select your language and click **"Continue"** 3. Enter your site details: Field Recommendation Site Title Your website name Username Something other than "admin" (for security) Password Use the strong password WordPress suggests Email Your email address 1. Click **"Install WordPress"** Congratulations! Your WordPress site is now live with HTTPS. ## Step 3 - Connect Your Domain Now let's connect your domain to your WordPress site. Server Compass handles SSL certificates automatically through Traefik and Let's Encrypt. ### Step 3.1 - Open the Domain tab 1. Click on your server to open its detail page 2. Click the **"Domain"** tab 3. Click **"+ Add Domain"** ![Click Add Domain button](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/1-add-domain-button.jpg) ### Step 3.2 - Configure domain settings Fill in the domain configuration: 1. **Traefik Setup Required** — Enter your email for Let's Encrypt SSL certificate notifications, then click **"Install Traefik"** (first time only) 2. **Domain Name** — Enter your domain (e.g., `yourdomain.com`) 3. **Application Port** — Select your WordPress container (`wordpress-wordpress-1`) from the list 4. **Enable SSL certificate** — Keep this checked for automatic HTTPS ![Fill in domain details](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/2-fill-in-email-for-ssl-your-domain-and-select-app.jpg) Click **"Continue"** to proceed. ### Step 3.3 - Configure DNS at your registrar Server Compass shows you your VPS IP address and verifies your DNS configuration: 1. Copy your **VPS IP address** shown on screen 2. Go to your domain registrar's DNS settings 3. Create an **A record** pointing to your server's IP: Type Host Value TTL A @ Your VPS IP (shown in Server Compass) 300 A www Your VPS IP 300 **Important:** If using Cloudflare, turn off the proxy (orange cloud -> grey cloud) before verifying. You can enable it again after SSL is configured. Once DNS is configured correctly, you'll see **"Domain verified successfully"** and **"DNS Configuration Verified!"**: ![DNS verification](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/3-configure-DNS-to-your-vps-IP.jpg) Click **"Configure Domain"** to complete the setup. ### Step 3.4 - Domain connected with SSL Your domain is now connected. Back on the **Apps** tab, you'll see your WordPress app now shows the HTTPS domain: ![Domain successfully applied](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/4-success-and-see-new-domain-applied.jpg) Server Compass automatically: - Configured Traefik to route traffic to your WordPress app - Obtained a free SSL certificate from Let's Encrypt - Enabled HTTPS for your site Click **"Open"** to visit your WordPress site with HTTPS enabled. You can now complete the WordPress setup wizard (Step 2.3). ## Step 4 - WordPress Database Management & Backup Server Compass provides tools for managing your WordPress database and creating backups. ### Step 4.1 - Access the database 1. Click on your WordPress app to open its detail page 2. Click the **"Database"** tab ![Database management tab](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/export-wordpress-db.jpg) You'll see your MySQL database with these options: Button Function **Admin** Open database admin interface **Import** Import a SQL dump file **Export** Export/backup your database **Credentials** View database connection details ### Step 4.2 - Export your database (backup) To create a database backup: 1. Click the **"Export"** tab 2. Enter a filename (e.g., `wordpress-backup.sql`) 3. Click **"Export and download"** This downloads a SQL dump file to your computer — save it somewhere safe. ### Step 4.3 - Import a database To restore or migrate a database: 1. Click the **"Import"** tab 2. Select your SQL dump file 3. Click **"Import"** This is useful for: - Restoring from a backup - Migrating from another WordPress installation - Bulk-updating URLs after a domain change ### Step 4.4 - Update WordPress 1. Click on your WordPress app 2. Click **"Redeploy"** to pull the latest image Your data persists because it's stored in Docker volumes, not inside the container. **Tip:** Always export your database before updating. ## Step 5 - Host Multiple WordPress Sites The power of this setup is running multiple sites efficiently on one server. Simply repeat the process. ### Step 5.1 - Add another WordPress site 1. On your server's **Apps** tab, click **"+ New App"** 2. Select **"App Template"** — search for **WordPress** 3. Configure with a different project name: Field Site 1 Site 2 Project Name `wordpress` `portfolio` 1. Click **"Deploy"** 2. Once deployed, go to the **Domain** tab and add a domain for the new site (same as Step 3) Server Compass handles everything automatically — Traefik detects the new container, routes traffic for the second domain, and obtains a new SSL certificate. ### Step 5.2 - How multiple sites work together Traefik inspects incoming requests and routes them based on the domain: ``` Request to site1.com -> WordPress container "wordpress" Request to site2.com -> WordPress container "second-wordpress" Request to site3.com -> WordPress container "wordpress-site3" ``` Each site is completely isolated with its own: - WordPress installation - MySQL database - SSL certificate - Docker volumes You can host 10+ sites on a single server (given adequate RAM). ### Step 5.3 - Verify your sites In Server Compass, you'll see all your WordPress apps listed with their domains and status: ![Multiple WordPress sites running](/blogs/beginner-host-multiple-wordpress-sites-no-terminal/images/repeat-many-sites.jpg) Each app shows: - **Running** status (green indicator) - **2 services** (WordPress + MySQL) - **HTTPS domain** configured - **Open** button to visit the site Visit each domain in your browser to confirm HTTPS is working. ## Conclusion You now have a production-ready setup for hosting multiple WordPress sites on a single Hetzner Cloud server. Each site runs in isolated Docker containers with automatic SSL certificates from Let's Encrypt. **What you've accomplished:** - Set up Server Compass with SSH key authentication - Created a Hetzner Cloud server - Installed Docker and Traefik with one click - Deployed WordPress with automatic SSL - Connected your domain - Learned how to manage, backup, and host multiple sites **Cost comparison:** Hosting Approach 3 WordPress Sites Annual Cost Managed WordPress Hosting $15-30/site/month $540-1,080 This setup (Hetzner CX12) €4.35/month total €52.20 (~$57) That's roughly **90% savings** while maintaining full control over your infrastructure. **Next steps:** - Add more WordPress sites by repeating Step 2 - Set up automated backups - Configure email sending with an SMTP plugin - Add uptime monitoring with a service like UptimeRobot --- **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. --- ## Self-Host Ollama on Your VPS: Run AI Models with One Click Source: https://servercompass.app/blog/self-host-ollama-vps-one-click Published: 2026-03-04 Tags: ai, ollama, self-hosted, templates, deployment Deploy Ollama on your VPS with one click. Browse and install AI models like Llama 3 and Mistral, test via integrated chat, and optionally bundle Open WebUI for a ChatGPT-like experience. Running AI models locally means no API costs, no rate limits, and complete data privacy. But setting up Ollama on a VPS typically involves SSH, Docker commands, port configuration, and figuring out how to expose the API securely. Server Compass v1.16.0 turns this into a one-click operation. Deploy Ollama from the Stack Wizard, manage models through a visual interface, and optionally bundle Open WebUI for a full ChatGPT-like experience—all on your own server. ## One-Click Ollama Deployment Select the Ollama template in the Stack Wizard, click Deploy, and Server Compass handles the Docker configuration, port mapping, and GPU passthrough (if available). Your Ollama instance is running in under a minute. ## Model Management Tab After deployment, a new Ollama tab appears in your app dashboard with full model management: - **Browse models** — search the Ollama library for Llama 3, CodeLlama, Mistral, Phi, Gemma, and hundreds more - **Install with one click** — download and configure models without CLI commands - **Monitor running models** — see memory usage per model to manage your VPS resources - **API endpoint access** — copy the API URL for use in your applications - **Integrated chat interface** — test models directly in Server Compass before integrating them ## Ollama + Open WebUI Bundle Want a polished chat interface for your team? Deploy the Ollama + Open WebUI bundle. Open WebUI provides a ChatGPT-like experience with conversation history, model switching, and multi-user support—all running on your VPS. ## 5 New CMS Templates Also in this release: one-click templates for Concrete CMS, Grav (flat-file CMS), MyBB (forum), OctoberCMS (Laravel-based), and phpMyAdmin. ## Password Generator The new password generator icon appears next to password fields throughout Server Compass. Generate secure passwords from 8 to 128 characters with configurable character types—no more using "password123" for your staging databases. ## Run AI on Your Own Server Self-hosting AI models gives you unlimited inference with zero API costs. [Try Server Compass](https://servercompass.app) and deploy Ollama in one click. --- **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. --- ## How to Run Qwen3.5-9B Locally with LM Studio for OpenClaw Source: https://servercompass.app/blog/run-qwen-locally-lm-studio-openclaw Published: 2026-03-04 Tags: self-hosted, ai, local-llm, tutorials Run your own AI agent entirely on your machine using LM Studio and OpenClaw — no API costs, no data leaving your computer, just 3 steps to full local inference. Want to run AI agents without sending your data to external APIs? With LM Studio and OpenClaw, you can run Qwen3.5-9B entirely on your local machine—no API costs, complete privacy, and full control over your inference pipeline. This guide walks you through the three steps to get a local AI agent running on your machine. ## Why Run AI Models Locally? Running large language models locally offers several advantages: - **Privacy**: Your data never leaves your machine - **No API costs**: Pay once for the hardware, run unlimited inference - **Low latency**: No network round-trips for each request - **Offline capability**: Works without an internet connection - **Full control**: Customize model parameters, context length, and behavior ## Step 1: Install LM Studio LM Studio is a desktop application that makes it easy to download, run, and serve local LLMs. It handles all the complexity of model loading, quantization, and serving an OpenAI-compatible API. 1. Visit [lmstudio.ai](https://lmstudio.ai) 2. Download the installer for your operating system (Windows, macOS, or Linux) 3. Run the installer and follow the setup wizard LM Studio requires a decent GPU for optimal performance, but can also run on CPU-only systems (albeit slower). For Qwen3.5-9B, you'll want at least 16GB of RAM or a GPU with 8GB+ VRAM. ## Step 2: Download Qwen3.5-9B Qwen3.5-9B is a capable 9-billion parameter model that strikes a good balance between speed and quality. It's excellent for coding tasks, drafting, and general assistance. 1. Open LM Studio 2. Go to the model browser or visit [lmstudio.ai/models/qwen/qwen3.5-9b](https://lmstudio.ai/models/qwen/qwen3.5-9b) 3. Click Download to fetch the model weights The download size is typically 5-10GB depending on the quantization level. Choose Q4\_K\_M for a good balance of quality and memory usage, or Q8\_0 if you have the VRAM to spare. ## Step 3: Load the Model and Start the Server Once downloaded, you need to load the model and start the local inference server: 1. Go to the **Chat** tab in LM Studio 2. Select Qwen3.5-9B from the model dropdown 3. Click **Load** to load the model into memory 4. Switch to the **Developer** tab 5. Click **Start Server** ![LM Studio Developer tab showing how to load Qwen3.5-9B model and start the local server](/app-screenshots/lm-studio-load-model.jpg) The server runs at `http://127.0.0.1:1234` by default. You can verify it's working by visiting: ``` http://127.0.0.1:1234/v1/models ``` You should see a JSON response listing your loaded model. Your local AI is now ready to accept requests. ## Using Qwen as a Sub-Model in OpenClaw Small local models like Qwen3 9B are great for fast drafting and coding tasks, but they come with important security considerations. Smaller models are: - More susceptible to prompt injection attacks - Less reliable at following tool-safety rules - Easier to manipulate into unintended behaviors For this reason, we recommend using local models as **subagents** rather than your main agent. ### Recommended Pattern The safest approach is a hybrid architecture: - **Main agent**: Use a top-tier model (Claude Opus, GPT-5) with full tool access - **Subagent**: Use Qwen3 only for contained tasks (summaries, refactors, drafts) - **Sandboxing**: Restrict tools so even if the subagent is manipulated, the blast radius is minimal ### Why This Matters Consider these risk scenarios: - **Untrusted inbox risk**: If your agent reads content from Reddit, Telegram, or the web, that content could contain prompt injection attacks. Smaller models are more likely to comply with malicious instructions. - **Tool misuse risk**: Web, browser, and file tools can leak sensitive data if the model is coerced into using them improperly. - **Containment**: A subagent with no web access and strict sandboxing can't roam your system or exfiltrate data. ### Configuration for a Locked-Down Qwen Worker Here's an example OpenClaw configuration that creates a secure Qwen worker: ``` { "agents": { "list": { "qwen-worker": { "model": "lmstudio/qwen3.5-9b", "sandbox": { "mode": "all" }, "tools": { "deny": ["group:web", "browser"] } } } } } ``` This configuration: - Points to your local LM Studio server - Enables full sandboxing for all operations - Denies access to web and browser tools You can then spawn this worker for bounded tasks from your main agent, or configure OpenClaw to use it as a subagent automatically. ## Best Practices for Local AI Agents - **Never use local models as your main inbox agent** that processes untrusted content - **Always sandbox subagents** with minimal tool permissions - **Use local models for bounded tasks**: code refactoring, summarization, draft generation - **Keep sensitive operations** (file writes, web requests, system commands) on your main agent with a more capable model - **Monitor resource usage**: local models can consume significant RAM and GPU resources ## Conclusion Running Qwen3.5-9B locally with LM Studio and OpenClaw gives you a powerful, private AI assistant. Your data stays on your machine, you pay no API costs, and you have complete control over the inference pipeline. Just remember: use local models as specialized workers for contained tasks, not as your primary agent handling untrusted inputs. With the right architecture, you get the best of both worlds—the privacy of local inference and the reliability of top-tier cloud models for critical operations. Your AI agent now runs 100% locally. Happy building. --- **Related in the StoicSoft network** If you work in AI-assisted coding, shared terminal sessions, or agent-driven shell workflows like the ones above, [1devtool](https://1devtool.com) is the StoicSoft network's tool for safer AI-assisted terminal work — shared sessions with auditing, preflight policy, and tiered model routing built in. 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. --- ## Why Self-Hosting Is the Smartest Move for Developers: Cheap, Fast, and Fully Under Your Control Source: https://servercompass.app/blog/why-self-hosting-is-the-smartest-move-for-developers Published: 2026-03-01 Tags: self-hosted, deployment, docker, vps-deploy Self-hosting gives you full control over your data, cuts hosting costs by 80%, and eliminates vendor lock-in. Here is why developers are switching from PaaS to self-hosted VPS deployments, and the best open-source tools you can deploy today. Every month, thousands of developers open their Vercel, Railway, or Render invoices and feel the same sting. A few side projects, a staging environment, maybe a production app — and suddenly you're paying $50, $100, or even $200+ per month for what amounts to a few Docker containers running on someone else's server. There's a better way. Self-hosting on your own VPS gives you the same capabilities — often better — at a fraction of the cost. And with modern tools, you don't need to be a DevOps engineer to make it work. ## The Real Cost of PaaS Platforms Let's look at what developers actually pay for managed platforms: - **Vercel Pro**: $20/month per team member, plus bandwidth overages and serverless function charges — see our [Vercel alternative](/vercel-alternative) - **Railway**: Usage-based pricing that scales quickly — a simple Node.js app can cost $5-15/month, and adding a database doubles that — see our [Railway alternative](/railway-alternative) - **Render**: $7/month per web service, $7/month per database — a typical stack costs $20-40/month — see our [Render alternative](/render-alternative) - **Heroku**: $5-25/month per dyno, plus $5-200/month for add-ons — see our [Heroku alternative](/heroku-alternative) Now compare that to a VPS: a $5-10/month server from Hetzner, DigitalOcean, or Vultr can run **multiple applications**, databases, and services simultaneously. The same workload that costs $80+ on PaaS platforms runs comfortably on a single VPS for $10/month or less. ## Why Self-Hosting Wins ### 1\. Dramatically Lower Costs A $6/month VPS with 4GB RAM and 2 vCPUs can comfortably host 5-10 Docker containers. That means your Next.js frontend, your API server, PostgreSQL, Redis, and a monitoring stack can all run on a single machine. On Vercel + Railway + a managed database, that same setup would cost $50-100/month. Over a year, that's the difference between $72 and $600-1,200. For indie developers and small teams, those savings compound fast. ### 2\. Full Control Over Your Data When you self-host, your data lives on **your** server. No third-party has access to your database, your environment variables, or your application logs. This matters for: - **Privacy compliance** — GDPR, HIPAA, and other regulations are simpler when you control exactly where data is stored - **Client trust** — agencies can tell clients their data never leaves a server they control - **Intellectual property** — your source code and build artifacts stay on your infrastructure - **Security** — fewer attack surfaces when there's no middleman between you and your server ### 3\. No Vendor Lock-in PaaS platforms love lock-in. Vercel's edge functions, Railway's proprietary networking, Render's managed databases — they all work slightly differently from standard tooling. When you need to migrate, you're rewriting infrastructure code. Self-hosted applications run on standard Docker containers. Move to any VPS provider, any cloud, or even bare metal — your apps work the same way everywhere. Your deployment is never tied to a specific vendor's ecosystem. ### 4\. Performance You Control On a PaaS, you're sharing resources with other tenants. Cold starts, throttled bandwidth, and noisy neighbors are facts of life. With your own VPS: - No cold starts — your apps are always running - Dedicated CPU and RAM — no resource contention - Choose your server location — put your app close to your users - Scale vertically with one click — need more RAM? Resize the VPS ### 5\. Unlimited Apps and Services PaaS platforms charge per service. Every database, every worker process, every cron job is another line item. On your VPS, you can run as many containers as your server resources allow — no per-service fees. ## The Old Problem: Self-Hosting Was Hard Historically, the trade-off was clear: PaaS platforms were expensive but easy. Self-hosting was cheap but required DevOps knowledge — SSH, Docker, Nginx, SSL certificates, CI/CD pipelines, monitoring, and more. That trade-off no longer exists. Tools like [Server Compass](/) bridge the gap by giving you the polished deployment experience of a PaaS platform while keeping everything on your own VPS. No agents or dashboards installed on your server — it connects via SSH only when needed. Plus, with free tools like our [Dockerfile generator](https://docker.servercompass.app/) and [Nginx config generator](/tools/nginx-config-generator), you can create production-ready configurations in seconds. ![Server Compass template gallery showing 100+ one-click deployment templates](/app-screenshots/feature-templates.jpg) ## What You Can Self-Host Today Here are some of the most popular self-hosted applications developers are deploying on their own VPS — all available as one-click templates in Server Compass: ### Databases - [PostgreSQL](/templates/postgresql) — The most popular open-source relational database. Self-hosting means no connection limits, no storage caps, and full control over extensions and configurations. - [MySQL](/templates/mysql) / [MariaDB](/templates/mariadb) — Battle-tested relational databases for WordPress, Laravel, and traditional web stacks. - [MongoDB](/templates/mongodb) — Document database for flexible schemas. A managed MongoDB Atlas cluster starts at $57/month — self-hosting costs $0 extra on your existing VPS. - [Redis](/templates/redis) — In-memory caching and message broker. Essential for any production app, and free when self-hosted. ### CMS and Content Platforms - [WordPress](/templates/wordpress) — Powers 43% of the web. Self-hosting gives you full plugin freedom, no bandwidth limits, and complete theme control. - [Ghost](/templates/ghost) — Modern publishing platform. Ghost Pro costs $9-199/month — self-hosting costs just your VPS bill. - [Strapi](/templates/strapi) — Headless CMS with a visual content editor. Deploy with PostgreSQL in one click. - [Directus](/templates/directus) — No-code data platform that wraps any SQL database with a REST and GraphQL API. See how easy it is to deploy Ghost CMS with one click: ### Development Tools - [Gitea](/templates/gitea) — Lightweight GitHub alternative. Host your own Git repositories with issues, pull requests, and CI/CD. Runs on as little as 256MB RAM. - [Drone CI](/templates/drone) — Container-native CI/CD platform that integrates with Gitea and GitHub. - [Jenkins](/templates/jenkins) — The most popular open-source automation server for building, testing, and deploying code. Self-host your own GitHub alternative with Gitea for $5/month: ### Monitoring and Analytics - [Grafana](/templates/grafana) — Beautiful dashboards for monitoring your infrastructure and applications. [Watch the tutorial](/tutorials/install-grafana-vps). - [Prometheus](/templates/prometheus) — Time-series monitoring and alerting. The industry standard for infrastructure metrics. [Watch the tutorial](/tutorials/install-prometheus-vps). - [Uptime Kuma](/templates/uptime-kuma) — Self-hosted uptime monitoring. Get notified when your services go down — without paying for a SaaS monitoring tool. [Watch the tutorial](/tutorials/deploy-uptime-kuma-vps). ### Productivity and Collaboration - [Mattermost](/templates/mattermost) — Open-source Slack alternative. Self-host your team chat without per-user fees. [Watch the tutorial](/tutorials/self-host-mattermost-vps). - [n8n](/templates/n8n) — Workflow automation platform (like Zapier). The cloud version starts at $20/month — self-hosting is free. - [NocoDB](/templates/nocodb) — Open-source Airtable alternative. Turn any database into a spreadsheet interface. ### Backend as a Service - [Supabase](/templates/supabase) — Open-source Firebase alternative with PostgreSQL, auth, storage, and real-time subscriptions. Supabase Pro costs $25/month per project — self-host unlimited projects on your VPS. - [Appwrite](/templates/appwrite) — Backend platform with auth, databases, storage, and functions. - [PocketBase](/templates/pocketbase) — Lightweight backend in a single binary. Perfect for mobile apps and small projects. Deploy your own Supabase instance in minutes: ![Server Compass app dashboard showing running containers with CPU and memory usage](/app-screenshots/feature-container-status.jpg) ## Deploy Your Own Code Too Templates are great for off-the-shelf software, but most developers also need to deploy their own applications. Server Compass supports [16+ frameworks](/features/framework-detection) out of the box: - **Frontend**: Next.js, React, Vue, Nuxt, Svelte, SvelteKit, Angular, Astro - **Backend**: Express, NestJS, Fastify, Django, Flask, FastAPI, Laravel, Go, Rust Connect your GitHub repo, select a branch, and deploy. Server Compass auto-detects your framework, generates a Dockerfile, and handles the entire build and deployment pipeline — including [zero-downtime blue-green deployments](/features/zero-downtime). ![Server Compass framework auto-detection showing detected project type and generated Dockerfile](/app-screenshots/feature-framework-detect.jpg) Here's how deploying a Next.js app to your VPS looks in practice: More step-by-step deployment tutorials: - [Deploy Django to VPS](/tutorials/deploy-django) - [Deploy SvelteKit to VPS](/tutorials/deploy-sveltekit-vps) - [Set up GitHub Actions CI/CD](/tutorials/deploy-vps-github-actions-cicd) - [Build locally, deploy instantly](/tutorials/build-locally-deploy-instantly) - [Deploy Laravel to VPS](/tutorials/deploy-laravel-vps) Need help with CI/CD? Generate complete pipelines with our [GitHub Actions generator](/tools/github-actions-generator) — no YAML expertise required. ## But What About Security? A common concern with self-hosting: "Am I responsible for security now?" Yes — but modern tools make this manageable. Server Compass includes built-in security features: - [Automatic SSL](/features/auto-ssl) with Let's Encrypt — every app gets HTTPS automatically - [UFW Firewall](/features/ufw-firewall) management — configure firewall rules visually - [Fail2ban](/features/fail2ban) — automatically ban IPs that show malicious behavior - [SSH Hardening](/features/ssh-hardening) — disable root login, enforce key-based auth with one click - [Security Audit](/features/security-audit) — scan your server for common vulnerabilities and misconfigurations - [.env Vault](/features/env-vault) — AES-256-GCM encrypted environment variables that never leave your machine ![Server Compass security audit showing system checks for SSH, firewall, and server configuration](/app-screenshots/feature-security-audit.jpg) ## The Self-Hosting Stack for $5/Month Here's what a complete self-hosted stack looks like on a single $5-10/month VPS: - **Your web app** (Next.js, Django, Laravel, etc.) - **PostgreSQL** for your database - **Redis** for caching and sessions - **Uptime Kuma** for monitoring - **Automatic SSL** via Let's Encrypt - **Automated backups** to S3-compatible storage Total cost: **$5-10/month**. The same stack on managed platforms would cost $70-150/month minimum. ## Getting Started with Self-Hosting If you're ready to take control of your infrastructure, here's how to get started in under 10 minutes: 1. **Get a VPS** — Hetzner, DigitalOcean, Vultr, or any provider. A $5-10/month plan with 2-4GB RAM is enough for most projects. 2. **Download Server Compass** — Available on Mac, Windows, and Linux. 3. **Connect your server** — Enter your VPS IP and credentials. Server Compass handles SSH setup automatically. [Watch the tutorial](/tutorials/connect-vps-no-ssh). 4. **Deploy your first app** — Pick a template or connect your GitHub repo. One click to deploy. ![Server Compass server overview showing connected server with running applications and resource usage](/app-screenshots/feature-server-overview.jpg) Watch how to connect your VPS and deploy your first app in under 2 minutes: No terminal commands. No YAML files to write. No Docker knowledge required. Server Compass handles the complexity so you can focus on building your product. ## Self-Hosting Is Not Just Cheaper — It's Smarter The shift toward self-hosting isn't just about saving money. It's about owning your infrastructure, controlling your data, and eliminating dependencies on platforms that can change pricing, shut down features, or deprecate APIs at any time. Your applications are your business. They should run on infrastructure you control. Ready to get started? [Try Server Compass today](/) — $19 one-time purchase, no subscription. Deploy unlimited apps to unlimited servers, with 100+ templates and built-in security. Your server, your rules. --- **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'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. --- ## How Server Compass Uses GitHub Actions for Zero-Downtime VPS Deployments Source: https://servercompass.app/blog/how-server-compass-uses-github-actions-for-zero-downtime-vps-deployments Published: 2026-02-26 Tags: github-actions, deployment, docker, ci-cd A deep dive into how Server Compass generates GitHub Actions workflows, encrypts secrets with libsodium sealed boxes, and performs blue-green deployments on your VPS. If you've tried setting up CI/CD for a VPS, you know it's painful. Writing GitHub Actions workflows from scratch, managing SSH keys, configuring Docker registries, handling secrets securely, implementing zero-downtime deployments — each piece takes hours to get right. Server Compass automates the entire pipeline. Click a button, and you get a production-grade GitHub Actions workflow that builds your Docker image, pushes it to GHCR, and deploys it to your VPS with zero downtime. This post explains exactly how it works under the hood. ## The Problem: CI/CD for VPS Is Hard Platforms like Vercel and Railway handle deployment automatically. Push to `main`, and your app is live. But when you self-host on a VPS, you're on your own. A typical DIY CI/CD setup for a VPS requires: 1. Writing a GitHub Actions workflow YAML file 2. Generating SSH keys and adding them to GitHub Secrets 3. Configuring Docker build and push to a container registry 4. Writing deployment scripts that SSH into your server 5. Handling environment variables securely 6. Implementing some form of health checking 7. Figuring out zero-downtime deployment (or just accepting brief outages) Most developers spend 4-8 hours getting this right. And when something breaks, debugging a workflow YAML file is nobody's idea of fun. **Server Compass reduces this to one click.** ## The 5-Phase Pipeline When you choose "Build with GitHub Actions" in Server Compass, it orchestrates a 5-phase deployment pipeline: ![Server Compass GitHub Build Setup showing the 5-phase deployment pipeline: Commit Build Files, Detect Workflow, Build and Push, Environment Variables, and Pull and Deploy](/app-screenshots/feature-github-actions.jpg) ### Phase 1: Commit Build Files Server Compass generates two files and commits them to your repository: - **A GitHub Actions workflow** at `.github/workflows/server-compass-docker-[app-name].yml` - **A Dockerfile** (if your project doesn't already have one) — auto-generated based on framework detection The workflow is fully customizable. You can review it before pushing, edit it in the built-in YAML editor, or reset it to the default. Server Compass commits these files directly to your chosen branch using the GitHub API. ![Server Compass workflow editor showing the generated GitHub Actions YAML with syntax highlighting, concurrency settings, and Push to my repo button](/app-screenshots/feature-workflow-mgmt.jpg) ### Phase 2: Detect Workflow Run After committing the workflow file, Server Compass watches for the GitHub Actions run to start. It polls the GitHub API to find the workflow run triggered by the commit, tracking the run ID for real-time status updates. If a `workflow_dispatch` event is used (for manual deployments), Server Compass triggers it directly via the API and immediately begins tracking. ### Phase 3: Build & Push to GHCR The workflow runs on GitHub's runners (2-core CPU, 7GB RAM — far more than most budget VPS instances). It: 1. Checks out your repository 2. Logs into GitHub Container Registry using the auto-generated `GITHUB_TOKEN` (no additional credentials needed) 3. Builds your Docker image using `docker/build-push-action` 4. Pushes the image to `ghcr.io/[your-username]/[app-name]` The build uses Docker layer caching from the registry, so subsequent builds are significantly faster. A typical Next.js app builds in 3-5 minutes on the first run and 1-2 minutes on subsequent runs. ![Server Compass real-time build tracking showing GitHub Actions workflow status, timestamped logs, and View on GitHub link](/app-screenshots/feature-build-logs.jpg) ### Phase 4: Environment Variables Server Compass encrypts your environment variables and stores them as GitHub Secrets. This is where the security gets interesting. GitHub Secrets use **libsodium sealed box encryption**. Each repository has a public key. To create a secret, you must: 1. Fetch the repository's public key from the GitHub API 2. Encrypt the secret value using `crypto_box_seal` (XSalsa20-Poly1305) 3. Send the encrypted value to GitHub Server Compass handles all of this automatically using `libsodium.js`. Your secrets are encrypted on your machine before being sent to GitHub — they never travel in plaintext. #### Special Handling for Next.js Next.js applications need `NEXT_PUBLIC_*` variables available at build time, not just runtime. Server Compass detects these variables, base64-encodes them, and stores them as a separate GitHub Secret (`NEXT_PUBLIC_ENV`). The workflow decodes them into an `.env` file before the Docker build step, ensuring they're baked into the client bundle. Runtime variables are injected via the `--env-file` flag when starting the container, so they're available to your server-side code without rebuilding. ### Phase 5: Pull & Deploy (Blue-Green) This is where the magic happens. Instead of simply restarting your container (which causes downtime), the workflow performs a **blue-green deployment**: `# Simplified version of the deploy steps - name: Pull image run: docker pull ghcr.io/user/app:latest - name: Start staging container run: | docker run -d --name app-staging \\ --env-file .env \\ -l traefik.enable=true \\ ghcr.io/user/app:latest - name: Health check (5 probes over 15 seconds) run: | for i in 1 2 3 4 5; do curl -sf http://localhost:PORT/ sleep 3 done - name: Swap containers run: | docker stop app-production docker rm app-production docker rename app-staging app-production` 1. **Pull the image** from GHCR to the VPS 2. **Start a staging container** alongside the existing production container, with Traefik routing labels 3. **Run 5 health probes** over 15 seconds to verify the new container responds correctly 4. **If healthy:** Stop the old container, rename staging to production 5. **If unhealthy:** Remove the staging container, keep the old one running. The deployment fails safely — your users never see an error During the swap, Traefik handles request routing automatically. Users hitting your app during deployment get served by whichever container is available. The result: zero perceived downtime. ## Automatic SSH Key Management For GitHub Actions to deploy to your VPS, it needs SSH access. Setting this up manually involves generating keys, copying them to the right places, and storing them securely. Server Compass automates all of it: 1. **Generates an Ed25519 key pair** locally on your machine — the most secure SSH key type 2. **Adds the public key** to your VPS's `~/.ssh/authorized_keys` 3. **Encrypts the private key** with GitHub's repository public key using sealed box encryption 4. **Stores it as a GitHub Secret** (`VPS_SSH_KEY`) The private key is never stored on your machine or in Server Compass. It goes from memory directly to GitHub Secrets, encrypted end-to-end. Each app gets its own SSH key. If one key is compromised, your other deployments remain secure. You can also revoke a key by removing it from your VPS's `authorized_keys` file. ## Framework Detection and Dockerfile Generation Most deployment tools require you to write your own Dockerfile. Server Compass generates one automatically by analyzing your project: ![Server Compass auto-detecting Node.js framework with package manager and generating deployment configuration](/app-screenshots/feature-framework-detect.jpg) **Detection process:** 1. Reads your `package.json`, `requirements.txt`, `go.mod`, `Cargo.toml`, or `Gemfile` 2. Identifies the framework: Next.js, React, Vue, Nuxt, Express, NestJS, Django, Flask, FastAPI, Go, Rust, Rails, or static HTML 3. Detects the package manager: pnpm (via `pnpm-lock.yaml`), yarn (via `yarn.lock`), bun (via `bun.lockb`), or npm (via `package-lock.json`) 4. Generates a multi-stage Dockerfile optimized for that specific stack For example, a Next.js project with pnpm gets a Dockerfile that uses `corepack enable` for pnpm, multi-stage builds for smaller images, and Next.js standalone output for minimal production deployments. A Python Django project gets a Dockerfile with pip install, collectstatic, Gunicorn, and the correct Python version. If you already have a Dockerfile, Server Compass uses it as-is. No interference. ## Docker Auto-Installation Deploying to a fresh VPS that doesn't have Docker? Server Compass detects the missing dependency and automatically installs Docker using the official `get.docker.com` installation script. It works across all major Linux distributions: - Ubuntu / Debian - CentOS / RHEL / AlmaLinux / Rocky Linux - Fedora - Arch Linux No manual setup. Just point Server Compass at a fresh VPS with SSH access, and it handles the rest. ## Concurrency and Deploy-Only Mode The generated workflow includes smart concurrency settings: `concurrency: group: server-compass-docker-[app-name]-main cancel-in-progress: true` If you push multiple commits quickly, only the latest one deploys. Previous in-progress workflow runs are automatically cancelled, saving GitHub Actions minutes. The workflow also supports a **deploy-only mode** via `workflow_dispatch`. This skips the build step and deploys the existing image — useful when you only changed environment variables and don't need a full rebuild. ## What the Generated Workflow Looks Like Here's a simplified version of the workflow Server Compass generates: `name: Docker Deploy - my-app concurrency: group: server-compass-docker-my-app-main cancel-in-progress: true on: push: branches: [main] workflow_dispatch: inputs: deploy_only: description: 'Skip build, deploy existing image' type: boolean default: false jobs: build: runs-on: ubuntu-latest if: github.event.inputs.deploy_only != 'true' steps: - uses: actions/checkout@v4 - uses: docker/login-action@v3 with: registry: ghcr.io username: \${{ github.actor }} password: \${{ secrets.GITHUB_TOKEN }} - uses: docker/build-push-action@v5 with: push: true tags: ghcr.io/user/my-app:latest cache-from: type=registry,ref=ghcr.io/user/my-app:cache cache-to: type=registry,ref=ghcr.io/user/my-app:cache deploy: needs: [build] runs-on: ubuntu-latest steps: - name: Deploy to VPS uses: appleboy/ssh-action@v1.0.3 with: host: \${{ secrets.VPS_HOST }} username: \${{ secrets.VPS_USERNAME }} key: \${{ secrets.VPS_SSH_KEY }} script: | # Pull latest image docker pull ghcr.io/user/my-app:latest # Blue-green deployment docker run -d --name my-app-staging ... # Health checks... docker stop my-app-production docker rename my-app-staging my-app-production` Server Compass generates the full version with proper health checks, Traefik labels, environment variable injection, error handling, and cleanup logic. You can customize any part of it. ## Real-Time Deployment Tracking You don't need to switch to GitHub to watch your deployment. Server Compass tracks everything in real-time: - **Workflow phases:** Commit Build Files → Detect Workflow → Build & Push → Environment Variables → Pull & Deploy - **Live logs:** Timestamped entries streamed directly from the deployment process - **View on GitHub:** One-click link to the full workflow run - **Background mode:** Close the deployment window and continue working. Server Compass notifies you when the deployment completes ## Auto-Deploy on Every Push Once the workflow is set up, every push to your configured branch triggers a new deployment automatically. Server Compass tracks all deployments in the Deployment History tab: ![Server Compass deployment history showing Git Push auto-deploy entries with commit hashes, GitHub Actions badges, and duration tracking](/app-screenshots/feature-auto-deploy.jpg) Each entry shows the trigger type (Git Push, Manual Deploy), commit hash and message, the GitHub Actions badge, and deployment duration. You can expand any entry to see the full deployment logs. ## When to Use GitHub Actions vs Other Build Methods Build Method Best For Trade-offs **Build on VPS** Powerful VPS (4GB+ RAM), simple apps, no GitHub needed Uses VPS resources during build, may OOM on small servers **Local Build** No GitHub account, privacy-sensitive projects, fast local machine Requires Docker locally, uploads image over network **GitHub Actions** Small VPS (<2GB RAM), auto-deploy on push, zero-downtime needed Requires GitHub, limited free minutes (2,000/month on free tier) For most developers deploying to budget VPS instances ($5-20/month), GitHub Actions is the recommended choice. Your VPS stays cool during builds, you get auto-deploy on push, and the blue-green deployment means zero downtime. ## Getting Started Setting up GitHub Actions deployment with Server Compass takes about 5 minutes: 1. **Connect your VPS** — Add your server with SSH credentials 2. **Connect GitHub** — OAuth flow stores your token locally in your system keychain 3. **Create a new app** — Select your GitHub repo and branch 4. **Choose "GitHub Actions"** as the build location 5. **Add environment variables** — Paste your `.env` file or add individually 6. **Deploy** — Server Compass generates the workflow, sets up SSH keys, encrypts secrets, and triggers the first deployment After the initial setup, every `git push` to your branch automatically builds and deploys your app. No manual intervention needed. **Server Compass is $29 — a one-time payment with no subscription. [Get it at servercompass.app](/).** Stop writing deployment scripts. Let Server Compass generate a production-grade CI/CD pipeline for your VPS in one click. --- **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. --- ## How to Self-Host PostgreSQL on Your VPS the Easy Way Source: https://servercompass.app/blog/how-to-self-host-postgresql-on-your-vps Published: 2026-02-26 Tags: self-hosted, deployment, docker, tutorials Deploy PostgreSQL to your own VPS in under 60 seconds with Server Compass. No SSH commands, no manual config — just one-click templates, a visual SQL editor, and automated backups. PostgreSQL is the world's most advanced open-source relational database. It powers everything from side projects to Fortune 500 companies. But self-hosting it on a VPS? That's where most developers hit a wall. Between SSH config, `apt-get` installs, `pg_hba.conf` edits, firewall rules, persistent storage, backups, and monitoring — what should be a 5-minute task turns into a 2-hour rabbit hole. And if you get the security wrong, your data is exposed to the entire internet. This guide shows you how to deploy PostgreSQL to your own VPS in under 60 seconds using [Server Compass](/) — no terminal, no manual config files, and no compromises on security. ## Why Self-Host PostgreSQL? Managed database services like AWS RDS, Supabase Cloud, or Neon are convenient, but they come with real costs: - **Price** — A small managed PostgreSQL instance costs $15–$50/month. A $5 VPS can run PostgreSQL alongside your entire application stack. - **Data sovereignty** — Your data lives on your server, in your region, under your control. No third-party access, no surprise data processing agreements. - **No connection limits** — Managed services often cap connections at 20–50 on starter tiers. Self-hosted PostgreSQL lets you configure `max_connections` to whatever your hardware supports. - **Full extension support** — Install any PostgreSQL extension you need: PostGIS, pgvector, TimescaleDB, pg\_cron, and more. No waiting for your provider to allowlist them. - **No vendor lock-in** — Your data is a standard PostgreSQL dump away from moving anywhere. The only downside has always been the operational overhead. That's exactly what Server Compass eliminates. ## The Hard Way: Manual PostgreSQL Setup Here's what a typical manual PostgreSQL deployment looks like. If you've done this before, feel free to skip to [the easy way](#deploy-postgresql-with-server-compass). ``` # SSH into your server ssh root@your-server-ip # Install PostgreSQL apt update && apt install -y postgresql postgresql-contrib # Switch to postgres user sudo -u postgres psql # Create a database and user CREATE USER myapp WITH PASSWORD 'supersecretpassword'; CREATE DATABASE mydb OWNER myapp; \\q # Edit pg_hba.conf to allow remote connections nano /etc/postgresql/16/main/pg_hba.conf # Add: host all all 0.0.0.0/0 md5 # Edit postgresql.conf nano /etc/postgresql/16/main/postgresql.conf # Change: listen_addresses = '*' # Restart PostgreSQL systemctl restart postgresql # Configure firewall ufw allow 5432/tcp # Set up backups (cron job) crontab -e # Add: 0 3 * * * pg_dump mydb > /backups/mydb_$(date +%F).sql # Set up monitoring... SSL... log rotation... ``` That's 15+ steps, and we haven't even covered persistent Docker volumes, automatic restarts, SSL/TLS for connections, or what happens when your server reboots. One typo in `pg_hba.conf` and your database either refuses all connections or accepts them from anyone. ## The Easy Way: Deploy PostgreSQL with Server Compass With Server Compass, the entire process takes three clicks and about 60 seconds. Here's how. ### Step 1: Open the Template Gallery In Server Compass, click **New App** and select **From Template**. The [template gallery](/features/template-deployment) includes 100+ pre-configured Docker stacks. ![Server Compass template gallery showing 100+ one-click deployment templates](/app-screenshots/feature-templates.jpg) Search for **"PostgreSQL"** or browse the **Database** category. You'll find the [PostgreSQL template](/templates/postgresql) ready to go. ### Step 2: Configure and Deploy The [Docker Stack Wizard](/features/docker-stack-wizard) lets you customize your PostgreSQL deployment before it goes live: - **Database name** — Set the default database via `POSTGRES_DB` - **Username and password** — Configure `POSTGRES_USER` and `POSTGRES_PASSWORD` - **Persistent volume** — Data is automatically stored on a Docker volume that survives container restarts, redeployments, and server reboots - **Port mapping** — Expose PostgreSQL on port 5432 (or any custom port) ![Docker Stack Wizard configuring a PostgreSQL deployment with environment variables](/app-screenshots/feature-stack-wizard.jpg) Hit **Deploy** and Server Compass handles the rest: pulling the official PostgreSQL Docker image, creating the volume, configuring the container, and starting the service. The entire process takes about 30–60 seconds depending on your server's internet speed. ### Step 3: Verify the Deployment Once deployed, the [container status](/features/container-status) panel shows your PostgreSQL instance running with real-time CPU and memory usage. You can see at a glance whether it's healthy and how many resources it's consuming. ## Manage Your Database Visually Deploying PostgreSQL is only half the story. You also need to create tables, run queries, import data, and monitor performance. Server Compass includes a full suite of database management tools — no separate pgAdmin installation required. ### Database Admin Panel The built-in [database admin interface](/features/db-admin) gives you a visual overview of your PostgreSQL instance. Browse databases, view table schemas, check column types and relationships — all from the same app you used to deploy. ![Server Compass database admin panel showing PostgreSQL tables and schema](/app-screenshots/feature-db-admin.jpg) ### SQL Query Editor Need to run a quick query? The [SQL editor](/features/sql-editor) supports syntax highlighting, result tables, and query history. Write `SELECT`, `INSERT`, `CREATE TABLE`, or any other SQL statement and see results instantly. ![SQL query editor with syntax highlighting and results table](/app-screenshots/feature-sql-editor.jpg) ### Tables and Schema Browser The [tables browser](/features/tables-browser) lets you explore your database structure visually. See all tables, their columns, data types, indexes, and constraints without writing `\dt` or `\d+ tablename` in a terminal. ![Tables and schema browser showing PostgreSQL table structure](/app-screenshots/feature-tables-browser.jpg) ### Data Import and Export Migrating data from another database? Use the [CSV import](/features/data-import) feature to upload data directly into your tables with column mapping and data preview. You can also [export](/features/data-export) tables and query results to CSV or JSON for backups, analysis, or migration. ## Secure Your Database Credentials Database passwords are the keys to your kingdom. Server Compass stores them in the [.env Vault](/features/env-vault), encrypted with AES-256-GCM and kept in your OS keychain. They never leave your machine and are never stored on any remote server. ![Environment variable vault showing encrypted PostgreSQL credentials](/app-screenshots/feature-env-vault.jpg) When your app needs to connect to PostgreSQL, just reference the environment variables in your Docker Compose configuration. Server Compass injects them securely at deploy time. See the [environment variables tutorial](/tutorials/manage-env-variables-env-vault) for a walkthrough. ## Set Up Automated Backups A database without backups is a disaster waiting to happen. Server Compass offers two backup strategies: ### Server-Level Backups The [server backups](/features/server-backups) feature creates full snapshots of your server's Docker volumes (including PostgreSQL data) and stores them locally or in S3-compatible storage (AWS S3, Backblaze B2, Cloudflare R2, MinIO). Schedule backups daily, weekly, or at any custom interval. ![Server backup configuration with S3-compatible storage options](/app-screenshots/feature-server-backups.jpg) ### Cron-Based pg\_dump For more granular control, set up a [cron job](/features/cron-scheduler) that runs `pg_dump` on a schedule. The [cron templates](/features/cron-templates) include pre-built database backup scripts you can customize. No more hand-editing crontab files — just pick a template, set the schedule visually, and you're done. ## Connect Your Apps to PostgreSQL Once PostgreSQL is running, connecting your application is straightforward. Use the standard connection string format: ``` postgresql://myuser:mypassword@your-server-ip:5432/mydb ``` If your app runs on the same server (which it probably does), use the Docker network hostname instead of the IP: ``` postgresql://myuser:mypassword@your-postgres-container:5432/mydb ``` Docker networking handles the routing automatically. No firewall rules to configure, no exposed ports to worry about. ### Popular Stacks with PostgreSQL Server Compass includes templates for the most popular PostgreSQL-backed applications. Each one deploys with PostgreSQL pre-configured: - [Strapi](/templates/strapi) — Headless CMS with PostgreSQL as the default database. See the [Strapi + PostgreSQL deployment tutorial](/tutorials/deploy-strapi-postgresql) . - [Supabase](/templates/supabase) — Full Firebase alternative built on PostgreSQL, with Auth, Realtime, and Studio. See the [self-host Supabase tutorial](/tutorials/self-host-supabase). - [Directus](/templates/directus) — Open-source headless CMS and data platform that wraps any SQL database in a real-time API. - [Ghost](/templates/ghost) — Professional publishing platform. While Ghost uses MySQL by default, many teams deploy it alongside a PostgreSQL instance for analytics or custom integrations. - [TimescaleDB](/templates/timescaledb) — Time-series extension for PostgreSQL, perfect for metrics, IoT data, and analytics workloads. ## Monitor Performance PostgreSQL performance depends on your server's resources. The [resource monitoring](/features/resource-monitoring) dashboard shows real-time CPU, memory, disk, and network usage. If your database starts consuming too much memory or your disk is filling up with WAL files, you'll see it immediately. Need to dig deeper? Open the [built-in SSH terminal](/features/ssh-terminal) and run PostgreSQL diagnostic queries directly, or check logs from the [container logs](/features/container-logs) panel. ## Security Best Practices Self-hosting a database means you're responsible for security. Server Compass helps with several layers: - **No exposed ports by default** — PostgreSQL runs inside Docker's internal network. Only apps on the same server can connect unless you explicitly expose the port. - **UFW firewall** — The [firewall manager](/features/ufw-firewall) lets you whitelist specific IPs if you do need external access to PostgreSQL. - **Fail2ban** — [Fail2ban](/features/fail2ban) blocks brute-force SSH attempts against your server, protecting the host that runs your database. - **SSH hardening** — The [SSH hardening](/features/ssh-hardening) feature disables password authentication and enforces key-based access to your server. - **Security audit** — Run a [one-click security audit](/features/security-audit) to check for common misconfigurations across your entire server. ## Cost Comparison: Self-Hosted vs Managed Here's a quick cost comparison for a typical indie developer or small team: Service Monthly Cost Storage Connections AWS RDS (db.t3.micro) ~$15–$25 20 GB 66 Supabase Pro $25 8 GB 60 direct Neon (Scale) $69 50 GB 500 Railway $5 + usage 1 GB free Unlimited **Self-hosted (Hetzner VPS)** **$4–$6** **40–80 GB** **Unlimited** A $5 Hetzner VPS gives you 40 GB of NVMe storage, 4 GB of RAM, and enough headroom to run PostgreSQL alongside your application, Traefik reverse proxy, and monitoring tools — all for less than the cheapest managed database tier. Add Server Compass at $29 one-time (no subscription), and you have a complete deployment and database management platform that pays for itself in the first month. ## Get Started in 60 Seconds Here's the complete workflow from zero to a running PostgreSQL instance: 1. **Download Server Compass** — [Install the desktop app](/) (Mac, Windows, or Linux) 2. **Connect your VPS** — Add your server with SSH credentials. See the [server connection tutorial](/tutorials/connect-server-password) if you need help. 3. **Deploy PostgreSQL** — Open the template gallery, search for PostgreSQL, configure your credentials, and click Deploy. 4. **Manage visually** — Use the SQL editor, tables browser, and admin panel to manage your database without ever opening a terminal. 5. **Set up backups** — Configure server backups or a cron-based `pg_dump` schedule. That's it. No SSH sessions, no config file editing, no firewall gymnastics. Just a PostgreSQL database running on hardware you own, managed through a visual interface. Ready to self-host your database? [Try Server Compass today](/) — $29 one-time, no subscription, no usage fees. --- **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. --- ## Build Docker Images Locally, Deploy to Your VPS via SSH Source: https://servercompass.app/blog/local-build-deploy-vps Published: 2026-02-25 Tags: docker, deployment, local-build, server-management, self-hosted Build Docker images on your own machine and stream them to your VPS via SSH. Three build methods, direct upload deployment, and unmanaged app scanning. Building Docker images on a $5 VPS with 1GB of RAM is slow. Node.js builds eat all the memory. Multi-stage builds time out. Your production server is doing double duty as a build server, and your users feel it. Server Compass v1.15.0 introduces Local Build—build Docker images on your own machine (with its fast CPU and plenty of RAM) and stream the result to your VPS via SSH. Your server only runs containers, never builds them. ## Three Build Methods Method Builds On Best For **Build on VPS** Your server Simple apps, powerful servers **Local Build** Your machine Large builds, small VPS, fast iteration **GitHub Actions** GitHub runners CI/CD pipelines, team workflows ## Upload Source Code Directly No GitHub repository? No problem. Pick a local folder from your machine and deploy directly. Server Compass auto-detects the framework—Node.js, Python, Django, Flask, and more—and generates the appropriate Dockerfile. This is perfect for quick prototypes, freelance client projects, or private repos you don't want connected to GitHub. ## Unmanaged App Scanner Already have Docker containers running on your server that you set up manually? The Unmanaged App Scanner finds them and lets you bring them under Server Compass management. You get monitoring, logs, domain management, and redeployment—without rebuilding anything. ## 8 Environment Types Label your deployments clearly: Alpha, Beta, QA, Demo, Development, Test, Staging, or Preview. Each type is visually distinct so you never accidentally push to production when you meant to update staging. ## Build Faster, Deploy Smarter Local Build is ideal for developers with powerful workstations and modest VPS plans. Build locally in seconds, deploy via SSH in seconds more. [Try Server Compass](https://servercompass.app) and pick the build method that fits your workflow. --- **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. --- ## Staging and Preview Environments: Test Before You Ship to Production Source: https://servercompass.app/blog/staging-preview-environments-activity-logs Published: 2026-02-24 Tags: deployment, staging, preview-environments, activity-logs, self-hosted Deploy staging environments for QA and preview environments for feature branches alongside production. One-click promote, auto-delete timers, and full activity logs with sensitive data redaction. You've built a feature and it works on your machine. Now what? Deploy it straight to production and hope for the best? Or spend an hour setting up a separate server with its own Docker stacks, environment variables, and domain just to test it? Server Compass v1.14.0 adds staging and preview environments—separate instances of your app running on the same server, each with its own port, environment variables, and lifecycle. ## Staging Environments Long-lived environments for QA and integration testing. A staging environment runs alongside your production app with its own configuration. Test database migrations, verify API changes, run automated tests—all on a dedicated instance that mirrors production. ## Preview Environments Temporary environments tied to feature branches. Deploy a preview for PR review, share the URL with your team, and let it auto-delete after 1 to 90 days. No cleanup needed—expired previews are removed automatically. ## Instant Access via Port Each environment gets its own port, accessible immediately without domain configuration. Server Compass scans your server and suggests an available port automatically. When you're ready, add a subdomain like `staging.yourapp.com`. ## One-Click Promote to Production Tested everything in staging? Promote to production with a single click. Server Compass handles the zero-downtime switch—your staging config becomes the new production config, and traffic switches instantly. ## Flexible Environment Variables Each environment gets its own environment variables. Copy from production as a starting point, customize for staging (different database, debug mode enabled), or import from your [.env Vault](/features/env-vault). ## Activity Logs: See Every Server Command Also new in this release: a complete log of every command Server Compass runs on your server. Filter by operation type, search across commands and output, and audit exactly what happened during each deployment. **Sensitive data is automatically redacted** — passwords, tokens, SSH keys, and secrets are masked in logs so you can share them safely for debugging. ## Before vs After Workflow Before After Test a feature branch Set up separate server or merge to main Click "Create Preview Environment" QA before production Deploy to production and test live Test in staging, then promote Clean up test environments Remember to delete manually Auto-delete after timer expires Audit server commands Check bash history via SSH Searchable activity log with redaction ## Ship with Confidence Staging and preview environments bring the workflow you know from Vercel and Railway to your own VPS. [Try Server Compass](https://servercompass.app) and test before you ship. --- **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. --- ## Encrypted Cloud Backups: Protect Your Server Config with S3-Compatible Storage Source: https://servercompass.app/blog/cloud-backup-s3-encrypted Published: 2026-02-22 Tags: backups, encryption, s3, server-management, self-hosted Back up your Server Compass configuration to Amazon S3, Backblaze B2, Wasabi, Cloudflare R2, and 5 more providers with AES-256-GCM encryption and scheduled automatic backups. Your VPS configuration is the product of hours of work. Server settings, Docker stacks, domain configurations, database credentials, cron jobs, alert rules—it's all there. If your laptop dies, your hard drive fails, or you accidentally delete your Server Compass data, how do you get it back? Server Compass v1.13.0 introduces cloud backups to any S3-compatible storage provider with military-grade encryption. Your data is encrypted before it ever leaves your computer. ## 9 Cloud Storage Providers Supported Connect to the storage provider you already use: - **Amazon S3** — the industry standard - **Backblaze B2** — cheapest per-GB storage - **Wasabi** — S3-compatible with no egress fees - **Cloudflare R2** — zero egress fees - **DigitalOcean Spaces** - **Vultr Object Storage** - **Hetzner Object Storage** - **MinIO** — self-hosted S3-compatible storage ## AES-256-GCM Encryption Every backup is encrypted with AES-256-GCM on your machine before uploading. The encryption key is derived from a passphrase that's stored in your operating system's keychain (macOS Keychain, Windows Credential Manager, or Linux Secret Service). The cloud provider never sees your unencrypted data. ## Scheduled Automatic Backups Set it and forget it. Schedule backups hourly, daily, weekly, or monthly. Combined with a retention policy that automatically deletes old backups, you get continuous protection without manual effort or unbounded storage costs. ## Preview Before You Restore Before restoring a backup, preview exactly what's inside—which servers, how many apps, which domains. Then choose to restore everything or selectively pick what you need. You can also download backups as `.scbackup` files for local archiving. ## What Gets Backed Up - Server connections and SSH credentials - App configurations and Docker stack definitions - Domain mappings and SSL settings - Environment variables and secrets - Cron job configurations - Alert rules and monitoring settings ## Never Lose Your Server Config Again Cloud backups work with any S3-compatible provider. Connect your storage, set a passphrase, enable scheduling. [Download Server Compass](https://servercompass.app) and protect your infrastructure configuration today. --- **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. --- ## Deploy NocoDB, Budibase, and Node-RED to Your VPS in One Click Source: https://servercompass.app/blog/no-code-templates-one-click-deploy Published: 2026-01-30 Tags: no-code, templates, self-hosted, deployment Self-host popular no-code and low-code platforms on your own VPS. One-click templates for NocoDB, Activepieces, Budibase, Node-RED, and ToolJet with auto-generated passwords. No-code platforms like NocoDB and Budibase are powerful—until you see the cloud pricing. NocoDB's hosted plan starts at $24/month per user. Budibase charges $50/month for 5 users. That adds up fast for a team tool. The alternative: self-host them on a $5/month VPS and own your data forever. Server Compass v1.8.0 makes this trivially easy with one-click deployment templates for five popular no-code and low-code platforms. ## New No-Code Templates ### NocoDB — Open Source Airtable Alternative Turn any database into a smart spreadsheet. NocoDB connects to your existing PostgreSQL or MySQL database and gives you a familiar spreadsheet UI with forms, kanban views, gallery views, and API generation. [Deploy NocoDB](/templates/nocodb) with Server Compass and keep your data on your own server. ### Budibase — Build Internal Tools Fast Build custom CRUD apps, dashboards, and admin panels without writing code. Budibase connects to SQL databases, REST APIs, and Google Sheets—then generates a full app with authentication, role-based access, and responsive layouts. ### Node-RED — Visual Workflow Automation Wire together APIs, hardware devices, and cloud services with a drag-and-drop editor. Node-RED is the go-to tool for IoT, home automation, and data pipeline prototyping. Self-hosting means your automations run 24/7 without cloud limits. ### Activepieces — Open Source Zapier Automate workflows between apps with a visual builder. Activepieces offers 100+ integrations and runs entirely on your server—no per-task pricing, no data leaving your infrastructure. ### ToolJet — Retool Alternative Build internal tools with a drag-and-drop interface. Connect to databases, APIs, and third-party services. Write custom JavaScript when you need to. Self-hosting ToolJet eliminates Retool's per-user pricing. ## Smart Template Configuration Each template comes pre-configured with: - **Auto-generated secure passwords** — database passwords and encryption keys generated automatically - **Auto-populated PUBLIC\_URL** — your server address filled in so the app knows where it lives - **Docker volume cleanup** — volumes are properly cleaned when removing apps to prevent stale data conflicts ## Cloud vs Self-Hosted Costs Platform Cloud Pricing Self-Hosted Cost NocoDB $24/user/month $0 (runs on your VPS) Budibase $50/month (5 users) $0 Activepieces $15/month (1,000 tasks) $0 (unlimited tasks) ToolJet $25/user/month $0 ## Self-Host in Minutes All five templates are available in the Stack Wizard now. Pick a template, customize environment variables if needed, click Deploy. [Try Server Compass](https://servercompass.app) and run your no-code stack on your own infrastructure. --- **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. --- ## Lock Down Your Domains: Security Headers, IP Allowlists, and Rate Limiting Source: https://servercompass.app/blog/domain-security-headers-rate-limiting Published: 2026-01-29 Tags: security, domains, ssl, traefik, server-management Configure HSTS, frame protection, Basic Auth, IP allowlists, and rate limiting per domain. Plus Force HTTPS toggle and WWW redirect with DNS verification. You deploy your app, set up a domain, and SSL is working. Job done, right? Not quite. Without security headers, your app is vulnerable to clickjacking. Without rate limiting, a bot can hammer your API. Without IP restrictions, your staging environment is public to the entire internet. Server Compass v1.7.4 redesigns the Domain Settings panel with three tabs—Overview, Security, and Redirects—giving you per-domain control over everything that matters. ## Security Headers Configuration Enable critical security headers with toggles instead of editing Traefik middleware YAML: - **HSTS (Strict-Transport-Security)** — forces browsers to use HTTPS, preventing downgrade attacks - **Frame protection (X-Frame-Options)** — blocks your site from being embedded in iframes, preventing clickjacking - **Content-Type sniffing protection** — prevents browsers from MIME-type guessing - **Force HTTPS** — per-domain toggle that redirects all HTTP traffic to HTTPS automatically ## Basic Auth and IP Allowlists Need to restrict access to a staging environment or admin panel? Add Basic Auth with a username and password—no middleware configuration files, just fill in the fields. Or lock it down further with an IP allowlist so only your office or VPN can reach it. This is especially useful for staging environments, internal dashboards, and admin panels that should never be publicly accessible. ## Rate Limiting Controls Protect your API endpoints from abuse with per-domain rate limiting. Set the request limit and time window, and Traefik handles enforcement at the proxy level—before requests even reach your application. ## SSL Certificate Status Display The Overview tab now shows your SSL certificate details at a glance—issuer, expiration date, and renewal status. No more guessing whether auto-renewal is working. ## WWW Redirect with DNS Checks Set up www-to-non-www redirects (or vice versa) with automatic DNS verification. Server Compass checks that both the root domain and www subdomain resolve correctly before configuring the redirect, preventing broken redirect loops. ## Secure Your Domains Every domain you add in Server Compass now comes with enterprise-grade security controls. No Traefik middleware files, no YAML debugging. [Try Server Compass](https://servercompass.app) and lock down your domains in minutes. --- ## Zero-Downtime Deployments: Ship Without Dropping a Single Request Source: https://servercompass.app/blog/zero-downtime-deployment-traefik-vps Published: 2026-01-16 Tags: deployment, zero-downtime, traefik, server-management, self-hosted Deploy without dropping a single request. Background building, instant Traefik traffic switching, health check verification, and automatic rollback on failure. Every deployment has a scary moment. You push the update, the old container stops, the new one starts building, and for 30 seconds to 2 minutes your users see nothing—or worse, an error page. For a side project, that's annoying. For a production app with paying customers, it's unacceptable. Server Compass v1.6.0 solves this with zero-downtime deployments powered by Traefik. Your current version keeps serving users while the new version builds in the background. When the new version is ready and healthy, traffic switches instantly. ## How Zero-Downtime Deployment Works ### Background Building When you trigger a deployment, Server Compass builds the new Docker image and starts the new container alongside the existing one. Your current version continues serving every request during the entire build process. No maintenance windows, no "deploying, please wait" pages. ### Health Check Verification Before switching traffic, Server Compass verifies the new container is actually healthy. It checks that the process started, the port is responding, and your health check endpoint returns a success status. If the new container fails to start or crashes on boot, traffic never switches to it. ### Instant Traffic Switching via Traefik Once health checks pass, Traefik atomically switches traffic from the old container to the new one. This isn't a DNS change that takes minutes to propagate—it's an in-memory routing update that happens in milliseconds. Not a single request is dropped. ### Automatic Rollback on Failure If the new container fails health checks, Server Compass automatically keeps the old container running. You get a clear error explaining what went wrong, and your users never noticed anything happened. You can fix the issue and try again without pressure. ## Per-Deployment or Default Strategy You can enable zero-downtime deployment as the default strategy for all apps, or toggle it per-deployment. Quick internal tools might not need it. Customer-facing production apps should always use it. ## Before vs After Scenario Standard Deploy Zero-Downtime Deploy During build App is down (30s – 2min) Old version serves requests New version crashes App stays down until fixed Old version keeps running automatically Traffic switch Hard restart with brief gap Instant Traefik routing update User experience Error pages during deploy Zero interruption ## Ship with Confidence Zero-downtime deployments mean you can ship updates any time—during peak hours, on a Friday afternoon, whenever your code is ready. No more scheduling maintenance windows or deploying at 3 AM. [Try Server Compass](https://servercompass.app) and deploy without dropping a single request. --- **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. --- ## Never Lose Your SSH Connection Again: Auto-Recovery and Database Table Browser Source: https://servercompass.app/blog/auto-reconnect-database-table-browser Published: 2026-01-14 Tags: database, ssh, server-management, self-hosted Automatic SSH reconnection with retry logic, plus a database table browser with data viewer, pagination, search, and smart record creation forms. You're in the middle of deploying an update when your SSH connection drops. Maybe your laptop switched Wi-Fi networks. Maybe your VPS provider had a blip. Either way, you're staring at a "Connection Lost" error and wondering if your deployment finished. Server Compass v1.4.4 handles this automatically. When a connection drops, the app reconnects up to 3 times with real-time progress feedback. No manual intervention, no lost state. ## Automatic Connection Recovery The new connection recovery system detects drops instantly and begins reconnecting. You see exactly what's happening—which retry attempt, whether authentication succeeded, and when the connection is restored. If your deployment was in progress, it picks up where it left off. This matters most during long-running operations: building Docker images, running database migrations, or transferring large files. A brief network hiccup no longer means starting over. ## Database Table Browser Building on the [DB Admin panel from v1.3.10](/blog/database-admin-panel-vps), the table browser now shows all your database tables with metadata at a glance—row count, table size, and column types. Click any table to see its data with pagination and search. ### Data Viewer with Pagination and Search Browse table rows with automatic pagination. Search across all columns to find specific records. This is the "quick check" workflow that database admins do dozens of times a day, without needing to write a `SELECT` query every time. ### Smart Record Creation Forms Need to insert a test record? The new creation form auto-detects field types from your table schema—text inputs for varchar columns, number inputs for integers, date pickers for timestamps, toggles for booleans. It even shows which fields are required and which have defaults. ## Who Benefits Profile Benefit Remote workers Unreliable Wi-Fi no longer disrupts deployments Database developers Browse and search table data without writing queries QA engineers Insert test records with auto-generated forms ## Try It Today Auto-recovery and the table browser are available now. [Download Server Compass](https://servercompass.app) and experience deployments that survive flaky connections. --- **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. --- ## Browse, Query, and Back Up Your Databases Without Leaving Your Desktop Source: https://servercompass.app/blog/database-admin-panel-vps Published: 2026-01-07 Tags: database, postgresql, mysql, mongodb, self-hosted Built-in database admin panel with credentials management, one-click backup/restore, SQL query editor, and table browsing for PostgreSQL, MySQL, and MongoDB. You deploy a PostgreSQL database alongside your app. Now you need to check if the migration ran. Your options: install pgAdmin, configure a connection through an SSH tunnel, or SSH in and type raw `psql` commands from memory. Each option takes minutes of setup for seconds of actual work. Server Compass v1.3.10 ships a built-in database admin panel that's automatically available for every database in your Docker stacks. No extra tools. No SSH tunnels. No port forwarding. ## Credentials Tab: Never Hunt for Database Passwords Again When you deploy a database template—or any Docker Compose stack with a database service—Server Compass extracts the credentials from your environment variables and displays them in a clean Credentials tab. - **Password management** — view, copy, or regenerate database passwords - **User management** — see which database users exist and their access levels - **Secure password generation** — generate strong passwords directly in the UI - **Connection strings** — pre-built connection URIs for your app's config ## One-Click Database Backups and Restore The new Data tab gives you push-button database backups. Click "Backup," and Server Compass runs the appropriate dump command (`pg_dump`, `mysqldump`, `mongodump`) inside the container and saves the result. Restoring is equally simple—upload a dump file and Server Compass handles the import. No more remembering whether it's `pg_dump -Fc` or `pg_dump -F c`, whether MySQL needs `--single-transaction`, or how to pipe `mongodump` output correctly. ## DB Admin: Browse Tables and Run Queries The DB Admin tab turns Server Compass into a lightweight [database management tool](/features/database-admin). Browse your tables, view stored procedures, and run SQL queries—all through the desktop app. This isn't meant to replace dedicated tools like pgAdmin or DataGrip for heavy database work. It's designed for the quick checks that happen dozens of times a day: "Did the user get created?" "What's in the sessions table?" "Did the migration add the new column?" ## Smart App Type Detection Templates are now categorized as **app**, **service**, or **database**. When Server Compass detects a database container, it automatically shows the Credentials, Data, and DB Admin tabs. No configuration needed. ## Before vs After Task Before After Check table data SSH in, connect to DB, type query Click DB Admin, browse table Find DB password Read .env file or docker-compose.yml Click Credentials tab Back up database SSH + remember dump command syntax Click "Backup" button Restore from backup Upload file, pipe to restore command Upload file, click "Restore" ## Try It Today Every database you deploy through Server Compass now includes a built-in admin panel. No plugins, no extra setup. [Download Server Compass](https://servercompass.app) and deploy your first database to see it in action. --- **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. --- ## From PM2 to Docker: How We Rebuilt VPS Deployments from Scratch Source: https://servercompass.app/blog/docker-traefik-deployment-revolution Published: 2025-12-31 Tags: docker, traefik, deployment, ssl, self-hosted Server Compass moves from PM2 to Docker containers with Traefik for automatic SSL, Docker Compose support, and easy rollbacks. Deploy any language to your VPS. If you've ever deployed a Node.js app to a VPS, you probably used PM2. It works—until it doesn't. You're stuck with one language runtime, SSL is a manual Nginx chore, and rolling back means SSH-ing in and praying your git history is clean. Server Compass v1.3.0 changes the foundation. Every deployment now runs inside a Docker container with Traefik handling domains and SSL automatically. This isn't a minor upgrade—it's a complete rethink of how apps get deployed to your VPS. ## Why Docker Changes Everything for VPS Deployments PM2 is a process manager for Node.js. That's it. If you want to deploy a Python app, a Go binary, or a PHP site alongside your Node.js API, you need entirely different tooling for each. Docker containers solve this by packaging every app with its own runtime, dependencies, and configuration. With Server Compass's Docker-powered deployments, you get: - **Language independence** — deploy Node.js, Python, Go, Rust, PHP, Ruby, or anything that runs in a container - **Isolated environments** — one app's dependencies never conflict with another's - **Consistent builds** — what works locally works on your server, every time - **Resource limits** — set CPU and memory caps per container so one runaway app can't take down your server ## Automatic SSL with Traefik: No More Nginx Config Files The old workflow for adding a domain to your VPS app: edit Nginx config, add a server block, run Certbot, set up renewal cron jobs, test the config, reload Nginx. Miss a semicolon and the whole proxy goes down. With Traefik as the reverse proxy, Server Compass handles all of this automatically. Point your domain's DNS to your server, click "Add Domain" in Server Compass, and Traefik: - Requests a [Let's Encrypt certificate](/features/ssl-management) automatically - Configures HTTPS with proper TLS settings - Routes traffic to the correct container - Renews certificates before they expire - Applies changes with zero downtime—no proxy reload required ## Docker Compose Support with Environment Variables Real apps aren't single containers. A typical deployment includes an app server, a database, maybe a Redis cache. Server Compass now supports Docker Compose files natively, so you define your entire stack in one file and deploy it as a unit. Each deployment gets its own set of environment variables. Database passwords, API keys, and configuration values are managed per-app, per-environment—not scattered across `.env` files on your server. ## One-Click Domain Setup with DNS Verification Adding a domain to your app is now a guided process. Server Compass verifies your DNS records are pointing to the right server before attempting SSL certificate generation. No more cryptic Certbot errors because your A record wasn't propagated yet. ## Easy Rollbacks to Previous Versions Every deployment creates a new container image. If something goes wrong, roll back to the previous version with one click. Server Compass keeps your [deployment history](/features/deployment-history) so you can see exactly what changed and when. No more SSH-ing into your server to run `git revert` and hoping for the best. Rollbacks are instant because the previous container image is still available. ## Before vs After Task Before (PM2 + Nginx) After (Docker + Traefik) Deploy a Python app Install Python, pip, virtualenv manually One-click with auto-detected Dockerfile Add SSL certificate Edit Nginx config + run Certbot Click "Add Domain" — automatic Roll back a bad deploy SSH in, git revert, restart PM2 One-click rollback in the UI Manage env variables Edit .env files via SSH Per-deployment env editor in the app Run multi-service apps Manually start each service Docker Compose deploys everything together ## Who Benefits Most Developer Profile How This Helps Full-stack developers Deploy frontend and backend as a single Compose stack Polyglot teams Run Node.js, Python, and Go apps on the same server without conflicts Solo founders Skip the DevOps learning curve — Docker is handled for you Agencies Manage multiple client apps with isolated environments and easy rollbacks ## Get Started The Docker + Traefik architecture is now the foundation of every Server Compass deployment. If you're still managing VPS apps with PM2 and manual Nginx configs, this is the upgrade that eliminates hours of DevOps busywork every month. [Try Server Compass](https://servercompass.app) and deploy your first Docker-powered app in under 5 minutes. --- **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. --- ## GUI app to deploy Docker apps to VPS in minutes without knowing command lines Source: https://servercompass.app/blog/gui-app-to-deploy-docker-apps-to-vps-in-minutes-without-knowing-command-lines Published: 2025-12-15 Tags: vercel-alternative, docker, deployment, github-actions Server Compass introduces visual Docker deployment for VPS with GitHub Actions build, local build, port conflict detection, framework detection for 16+ project types, and real-time tracking. ## The Problem: VPS Deployment Shouldn't Be This Hard If you've ever deployed an application to a VPS, you know the drill: 1. SSH into your server 2. Install Docker (if not already installed) 3. Create a directory for your app 4. Write a `docker-compose.yml` file (or copy-paste from the last project) 5. Create a `Dockerfile` (if you need custom builds) 6. Set up environment variables in a `.env` file 7. Run `docker compose up -d` 8. Wait... and hope nothing fails 9. Realize port 3000 is already in use 10. Debug for 20 minutes 11. Try again For a simple Next.js app, this process takes 30-60 minutes. And that's if everything goes right. **What if your VPS only has 512MB RAM?** Building a Next.js app will likely fail with out-of-memory errors. You'll need to either upgrade your server or build locally and push the image manually. This is the reality for thousands of developers deploying side projects, client work, and production apps to VPS instances. ## The Solution: Deploy New App Wizard Server Compass introduces a visual wizard that handles the entire deployment process for you: ### 1\. Choose Your Source Deploy from anywhere: - **GitHub Repository** — Connect your repo, select a branch, and deploy - **Container Registry** — Pull images from DockerHub, GHCR, GitLab, or private registries - **Pre-built Templates** — WordPress, PostgreSQL, Redis, MongoDB, Nginx, and more - **Paste YAML** — Already have a `docker-compose.yml`? Paste it in - **Upload Files** — Drag and drop your local project folder ### 2\. Configure Your App The wizard walks you through: - Project naming - Port configuration (with **automatic conflict detection**) - Docker Compose editing with real-time validation - Environment variables (individual fields or bulk paste) - Build settings and build location selection ### 3\. Choose Where to Build Here's where it gets interesting. Server Compass gives you three build options: ![Server Compass build location selection showing Build on VPS, Local Build, and GitHub Actions options with environment variables editor](/app-screenshots/feature-build-config.jpg) **Option 1: Build on VPS** - Docker images build directly on your server - Good for small apps and powerful VPS instances - No external dependencies **Option 2: Build Locally** - Docker images build on your local machine - Image is streamed to your VPS via SSH - Great when your laptop is more powerful than your VPS - No GitHub account required ![Server Compass local build in progress showing real-time deployment phases: Analyzing Project, Generating Dockerfile, Building Image, Uploading Image to server with progress bar and deployment logs](/app-screenshots/feature-local-build.jpg) **Option 3: Build with GitHub Actions** - Docker images build on GitHub's infrastructure (2-core CPU, 7GB RAM) - Pushed to GitHub Container Registry (GHCR) - Your VPS only pulls and runs the final image - **Perfect for small VPS instances that can't handle large builds** - Includes zero-downtime blue-green deployment via Traefik ### 4\. Review & Deploy Before deployment, Server Compass shows you: - Ports being used (with conflict detection) - Services being created - Environment variables - Resource requirements If there are any issues (port conflicts, invalid YAML, missing SSH keys), you'll know **before** the deployment fails. ### 5\. Watch It Happen Once you hit "Deploy", you'll see: ![Server Compass deployment progress showing real-time phases: Initializing, Preparing, Pulling Images, Building, Starting Containers, and Running with deployment logs](/app-screenshots/docker-support-1.jpg) - **Current phase:** Initializing → Preparing → Pulling Images → Building → Starting Containers → Running - **Progress percentage:** Estimated based on typical deployment times - **Live logs:** See exactly what's happening - **Error messages:** If something fails, you'll know why No more "is it working?" uncertainty. You'll know exactly what's happening and when it's done. ## GitHub Actions Build: The Game-Changer This is the feature we're most excited about. ### The Problem with Small VPS Instances A $4/month VPS with 512MB RAM is perfect for **running** applications. But **building** them? That's a different story. Try building a Next.js app with dependencies on a 512MB server: `$ docker compose build ... npm install # 10 minutes later Killed` Out of memory. Your build fails. Your options: 1. Upgrade to a more expensive VPS 2. Build locally and push images manually 3. Use a CI/CD service (complex setup) **Or use Server Compass with GitHub Actions build.** ### How It Works When you select "Build with GitHub Actions", Server Compass orchestrates a 5-phase deployment pipeline: ![Server Compass GitHub Build Setup showing the workflow editor with generated YAML, deployment phases (Commit Build Files, Detect Workflow, Build and Push, Environment Variables, Pull and Deploy), and Push to my repo button](/app-screenshots/feature-github-actions.jpg) 1. **Commit Build Files** — Generates an optimized GitHub Actions workflow and pushes it along with a Dockerfile to your repository 2. **Detect Workflow** — Waits for GitHub Actions to pick up the workflow and tracks the run ID 3. **Build & Push** — Builds your Docker image on GitHub's runners (2-core CPU, 7GB RAM) and pushes to GitHub Container Registry (GHCR) 4. **Environment Variables** — Configures secrets for your deployment using libsodium sealed-box encryption (XSalsa20-Poly1305) 5. **Pull & Deploy** — SSHs into your VPS, pulls the pre-built image, and starts the container with zero-downtime blue-green deployment ### Zero-Downtime Blue-Green Deployment The generated workflow doesn't just restart your container. It performs a blue-green deployment: 1. A new "staging" container starts alongside the existing one 2. Traefik routing labels are configured for the staging container 3. 5 health probes run over 15 seconds to verify the new container is healthy 4. Once healthy, the old container is stopped and removed 5. The staging container is renamed to become the production container Your users never see downtime. If the new version fails health checks, the old container keeps running. ### Automatic SSH Key Setup For GitHub Actions to deploy to your VPS, it needs SSH access. Server Compass handles this automatically: - Generates a fresh Ed25519 key pair locally - Adds the public key to your VPS `authorized_keys` - Encrypts the private key with GitHub's repository public key using libsodium sealed boxes - Stores it as a GitHub Secret — the private key never touches Server Compass's storage - Keys are scoped per-app so one compromised key doesn't affect others ### The Result Your $4/month VPS can now run applications it could never build. - **Build time:** 3-5 minutes on GitHub's infrastructure vs 20+ minutes (if it doesn't crash) on a small VPS - **VPS resource usage during build:** 0% (vs 100% CPU, 95%+ memory) - **Automatic deployments:** Push to your branch → GitHub builds and deploys automatically Plus, you get: - Build history on GitHub - Cached builds (faster subsequent deployments) - CI/CD out of the box - Ability to review builds before they deploy ### Real-Time Build Tracking You don't need to switch to GitHub to monitor your build. Server Compass streams the workflow status directly into the app: ![Server Compass showing real-time GitHub Actions build logs with workflow run status, deployment phases progress, and timestamped log entries](/app-screenshots/feature-build-logs.jpg) - Workflow status: queued, building, deploying, complete - Timestamped log entries streamed in real-time - Direct link to view the full workflow run on GitHub - Background deployment support — close the window and get notified when done ## Port Conflict Detection: Stop Failures Before They Happen One of the most frustrating deployment failures: `$ docker compose up -d Error: bind: address already in use` You SSH in, run `netstat -tuln`, grep for the port, find what's using it, change your config, try again. **Server Compass detects port conflicts before deployment.** ![Server Compass Port Management view showing all listening ports on the server with source labels (System, Docker), process names, PIDs, and associated domains](/app-screenshots/feature-ports.jpg) When you reach the Review step, Server Compass scans your server using both `docker ps` and `ss -ltn` (or `netstat -ltn` on older systems) to find: - Docker containers using ports - System services (nginx, Apache, sshd) - Database services (PostgreSQL, MySQL, Redis, MongoDB) - Node.js/PM2 processes If your app wants to use port 3000 and it's already taken, you'll see the conflict with details about what's using it. You can fix the conflict **before** deployment fails. ## Smart Framework Detection Don't have a Dockerfile? No problem. If you deploy a GitHub repository without a Dockerfile, Server Compass automatically detects your framework and generates an optimized Dockerfile: ![Server Compass framework detection showing auto-generated config for Node.js framework with package manager detection and branch selection](/app-screenshots/feature-framework-detect.jpg) **Supported frameworks (16+ project types):** - **JavaScript/TypeScript:** Next.js, React, Vue, Nuxt, Express, NestJS, generic Node.js - **Python:** Django, Flask, FastAPI, generic Python - **Go:** Go modules - **Rust:** Cargo projects - **Ruby:** Rails, generic Ruby - **Static:** HTML/CSS sites **Package manager detection:** Server Compass detects pnpm, yarn, bun, or npm based on your lock files and generates the correct install commands. For a Next.js app with pnpm, it generates a multi-stage Dockerfile: `FROM node:18-alpine AS deps WORKDIR /app COPY package.json pnpm-lock.yaml ./ RUN corepack enable && pnpm install --frozen-lockfile FROM node:18-alpine AS builder WORKDIR /app COPY --from=deps /app/node_modules ./node_modules COPY . . RUN corepack enable && pnpm run build FROM node:18-alpine AS runner WORKDIR /app COPY --from=builder /app/.next/standalone ./ COPY --from=builder /app/.next/static ./.next/static COPY --from=builder /app/public ./public EXPOSE 3000 CMD ["node", "server.js"]` Optimized for: - Multi-stage builds (smaller final image) - Layer caching (dependencies cached separately) - Production-only output - Correct package manager commands ## Real-World Examples ### Example 1: Deploying a Next.js Side Project **Before Server Compass:** `# SSH into VPS ssh root@vps.example.com # Create directory mkdir -p /var/www/my-app cd /var/www/my-app # Clone repo git clone git@github.com:me/my-app.git . # Create Dockerfile (if not exists) nano Dockerfile ... write Dockerfile ... # Create docker-compose.yml nano docker-compose.yml ... write compose file ... # Create .env nano .env ... add environment variables ... # Build (hope it doesn't OOM) docker compose build ... wait 15-20 minutes ... # Start docker compose up -d # Check if it's actually running docker compose ps curl localhost:3000` **Total time:** 45-60 minutes (if everything goes right) **With Server Compass:** 1. Click "New App" 2. Select "GitHub Repository" 3. Choose your repo and branch 4. Select your build location (VPS, Local, or GitHub Actions) 5. Review and deploy **Total time:** 5 minutes (mostly waiting for the build) ### Example 2: Deploying from a Template Need a PostgreSQL database? **Before Server Compass:** `ssh root@vps mkdir -p /var/www/postgres-db cd /var/www/postgres-db nano docker-compose.yml ... copy-paste from postgres docs ... nano .env ... set POSTGRES_PASSWORD ... docker compose up -d` **With Server Compass:** 1. Click "New App" 2. Select "Templates" 3. Choose "PostgreSQL" 4. Set password and port 5. Deploy **Total time:** 60 seconds ### Example 3: Client Project with Custom Registry **Before Server Compass:** `ssh root@client-vps docker login registry.gitlab.com ... enter credentials ... cd /var/www/client-app nano docker-compose.yml ... configure to pull from private registry ... docker compose pull docker compose up -d` **With Server Compass:** 1. Add container registry credentials (one-time) 2. Click "New App" 3. Select your registry 4. Paste docker-compose.yml 5. Deploy **Total time:** 2 minutes ## Environment Variable Management Environment variables are stored securely and synced automatically: ![Server Compass .env Vault showing encrypted environment variable collections organized by project, with AES-256-GCM encryption and import/export options](/app-screenshots/feature-env-vault.jpg) - **.env Vault:** Variables encrypted with AES-256-GCM and stored locally — they never leave your machine - **VPS sync:** Automatically creates `.env` files on your server during deployment - **Bulk paste:** Copy your entire `.env` file and paste it in — variables are automatically parsed and validated - **Next.js NEXT\_PUBLIC\_ handling:** Build-time variables like `NEXT_PUBLIC_*` are automatically base64-encoded and injected as a separate GitHub Secret so they're available during the Docker build step - **Runtime variables:** Injected via `env_file` directive in docker-compose.yml ## Deployment History and Rollbacks Every deployment is tracked with full logs, commit references, and status badges: ![Server Compass deployment history showing rollback and redeploy entries with success badges, deployment logs, and duration tracking](/app-screenshots/feature-deploy-history.jpg) - **Full deployment history:** See every deployment with status (success/failed), duration, and trigger type (Git Push, Manual Deploy, Rollback) - **One-click rollback:** Restore a previous version instantly - **Deployment logs:** Complete logs for every deployment with copy and expand options - **Git commit tracking:** See which commit triggered each deployment ## Container Monitoring Once deployed, Server Compass gives you a real-time view of your containers: ![Server Compass container overview showing WordPress and MySQL containers with real-time CPU and memory usage, port mappings, and controls for logs and restart](/app-screenshots/feature-container-controls.jpg) - **Container status:** Running, stopped, or unhealthy at a glance - **Resource usage:** Real-time CPU and memory per container - **Port mappings:** See which ports are exposed - **Quick actions:** Restart individual containers, view logs, or redeploy the entire stack ## Deployment Notifications Get notified when deployments finish — even when the app is closed: ![Server Compass deployment notifications with Discord integration showing deployment complete and failed alerts with server and status details](/app-screenshots/feature-deploy-notifications.jpg) - System notifications on your desktop - Discord, Slack, Email, or Webhook channels - Server Compass installs a lightweight notifier on your VPS so alerts work even when the app is closed ## Auto-Deploy on Git Push For GitHub Actions builds, every push to your configured branch triggers an automatic deployment: ![Server Compass auto-deploy showing deployment history with Git Push and Manual Deploy entries, commit hashes, and GitHub Actions badges](/app-screenshots/feature-auto-deploy.jpg) Push to `main` and your app is live in minutes. The deployment history shows the git commit hash and message for each deployment, so you always know exactly what version is running. ## Security Features ### Credential Encryption All sensitive data is encrypted: - **SSH passwords:** AES-256-GCM encryption - **SSH private keys:** Stored in credential vault - **Container registry credentials:** Encrypted at rest - **GitHub Secrets:** Encrypted with libsodium sealed boxes (XSalsa20-Poly1305) using GitHub's repository public key - **.env variables:** AES-256-GCM encrypted in the .env Vault, never leave your machine ### SSH Key Management For GitHub Actions deployments: - Ed25519 key pairs generated locally on your machine - Private keys never stored in Server Compass — they're sent directly to GitHub Secrets - Public keys added to your VPS `authorized_keys` - Keys scoped per-app (one compromised key doesn't affect others) ### Docker Auto-Installation Deploying to a fresh VPS with no Docker installed? Server Compass detects this and automatically installs Docker from the official `get.docker.com` script. No manual setup required. ## Technical Details For the curious: **Architecture:** - Desktop app: Electron + React - Local database: SQLite (better-sqlite3) - SSH execution: ssh2 library - Container orchestration: Docker Compose v2 - CI/CD: GitHub Actions with workflow\_dispatch - Container registry: GitHub Container Registry (GHCR) - Reverse proxy: Traefik (for blue-green deployments) - Encryption: libsodium.js sealed boxes + AES-256-GCM **System requirements:** - macOS 12+, Windows 10+, or Linux - VPS with Docker support (auto-installs if missing) - SSH access to VPS (root or Docker group) **Supported VPS providers:** - DigitalOcean, Linode, Vultr, Hetzner - AWS EC2, Google Cloud Compute - Any VPS with SSH access ## Get Started Today Ready to stop manually deploying to VPS? **Server Compass is $29. One-time payment. No subscription.** You get every feature, all future updates, and support. It works on Mac, Windows, and Linux. You can manage unlimited servers and deploy unlimited apps. Compare this to Vercel Pro at $240/year, or Railway at $200+/month once you're past their free tier. Server Compass pays for itself with your first month of VPS savings. **Quick Start:** 1. Download from [servercompass.app](/) 2. Add your VPS (SSH credentials) 3. Click "New App" 4. Follow the wizard 5. Watch your app deploy in real-time ## Final Thoughts We built Server Compass because we were tired of spending evenings debugging VPS deployments instead of building features. The Deploy New App feature represents hundreds of hours of work to make VPS deployment as simple as deploying to Vercel or Netlify — but with the control and cost-effectiveness of managing your own servers. Whether you're deploying side projects to $4/month VPS instances or managing client applications across multiple servers, Server Compass helps you focus on building, not infrastructure. Try it out and let us know what you think. We read every piece of feedback and use it to guide development. Happy deploying! --- **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. --- ## Server Compass vs Coolify: Best Self-Hosted Deployment Tools in 2025 Source: https://servercompass.app/blog/server-compass-vs-coolify-best-self-hosted-deployment-tools-in-2025 Published: 2025-12-13 Tags: self-hosted, coolify, deployment, vps Self-hosting apps like Nextcloud, Jellyfin, Coolify, or custom web projects is more popular than ever in 2025, thanks to rising PaaS costs. A good VPS gives you root access, dedicated resources, and controlu2014without the overhead of a full dedicated server. In 2025, developers and indie hackers are increasingly moving away from expensive **Platform as a Service (PaaS)** providers like [Vercel](/vercel-alternative), [Heroku](/heroku-alternative), [Netlify](/netlify-alternative), and [Railway](/railway-alternative) due to rising costs and vendor lock-in. Instead, they're turning to **self-hosted deployment tools** that run on cheap **VPS** providers like **DigitalOcean** or **Hetzner**. Two standout options are **Server Compass** and **Coolify**. Both enable **push-to-deploy** workflows with **automatic SSL**, previews, and more—but they take fundamentally different approaches. Server Compass is a **native desktop app** that manages your servers remotely, while Coolify is a **self-hosted web dashboard** installed directly on your server. This guide compares them head-to-head to help you choose the right **self-hosted PaaS alternative**. ## What is Server Compass? **Server Compass** is a native **desktop app** for Mac, Windows, and Linux that brings a polished, **Vercel-like deployment experience** directly to your own **VPS**. Unlike web-based tools, nothing is installed on your server except Docker—your credentials never leave your local machine. - Runs entirely on your local machine—no software, dashboard, or database installed on the server. - Connect via SSH, link your Git repo, and deploy with one click using [zero-downtime deployment](/features/zero-downtime) (blue-green). - [100+ one-click templates](/features/template-deployment) for popular stacks—[WordPress](/templates/wordpress), [PostgreSQL](/templates/postgresql), [Redis](/templates/redis), [MongoDB](/templates/mongodb), [Ghost](/templates/ghost), [Supabase](/templates/supabase-lite), and more. - [GitHub Actions CI/CD](/features/github-actions) pipeline generation—no YAML writing required. - Framework detection for **16+ project types** including Next.js, Django, Flask, Laravel, Go, Rust, and more. - [Database management](/features/db-admin) for PostgreSQL, MySQL, MongoDB, and Redis. - [.env Vault](/features/env-vault) with AES-256-GCM encryption, domain management with automatic SSL, [server backups](/features/server-backups) (local + S3-compatible), deployment history with one-click rollback, built-in terminal, file manager, cron job scheduler, and server monitoring. - Manages **unlimited servers** from a single desktop app. Pricing: **One-time purchase for $29**—no subscriptions, no recurring fees. ![Server Compass container management dashboard showing running containers with status, ports, uptime, and quick actions](/app-screenshots/feature-container-status.jpg) ## What is Coolify? **Coolify** is an **open-source self-hosted PaaS** with a powerful web-based dashboard that you install directly on your server(s) using Docker. It runs alongside your apps, providing a browser-accessible control plane. - Deploys **apps**, **databases** (PostgreSQL, MongoDB, Redis), and over 280 **one-click services** (e.g., WordPress, Plausible Analytics). - Supports **multiple servers**, **backups**, monitoring, **Git integration**, **automatic SSL**, and advanced builders like Nixpacks or Docker Compose. - Supports Docker Swarm for more advanced orchestration needs. - Optional **Coolify Cloud** (paid, starting ~$5/month) for managed dashboard without self-hosting the control plane. Self-hosted version: Completely free and open-source. ## Architecture: The Key Difference The biggest distinction between these tools is **where they run**: - **Server Compass** is a desktop app. It connects to your server over SSH, deploys via Docker, and stores all credentials locally on your machine with AES-256-GCM encryption. Your server only runs Docker and your apps—nothing else. - **Coolify** installs a web dashboard, reverse proxy, and database on your server. Your credentials are stored in a database on the server itself. The dashboard is accessible via browser, which is great for teams but means your server carries extra overhead. This architectural difference affects everything from security to resource usage to how you access the tool when you're away from your desk. ## Head-to-Head Comparison Feature Server Compass Coolify **Type** Local **desktop app** (no server install) **Self-hosted web dashboard** (Docker on server) **Server Overhead** None—only Docker on server Adds Docker, proxy, dashboard, and database **Pricing** One-time $29 Free (open-source); Cloud ~$5+/month **Templates** 100+ one-click templates 280+ one-click services **Databases** PostgreSQL, MySQL, MongoDB, Redis management Full database management **CI/CD** GitHub Actions pipeline generation Built-in CI/CD **Framework Detection** 16+ frameworks auto-detected Nixpacks auto-detection **Docker Support** Docker & Docker Compose Docker, Compose, Swarm **Build Options** VPS, Local, or GitHub Actions Server-based builds **Multi-Server** Unlimited servers Excellent multi-server **Backups** Local + S3-compatible Built-in backups **SSL** Automatic Let's Encrypt Automatic Let's Encrypt **Open Source** No (proprietary) Yes (GitHub) **Security Model** Credentials on your machine only Credentials on server **Best For** Solo devs, agencies, startups Teams needing full ecosystem ## Build Options: Three Ways to Build One area where Server Compass offers unique flexibility is **where your app gets built**. You can choose between three build locations: 1. **Build on VPS**—Docker builds run directly on your server. Simple and works for smaller apps. 2. **Build Locally**—your machine builds the Docker image and pushes it to the server. Keeps your VPS resources free for running apps. 3. **Build via GitHub Actions**—Server Compass generates a complete CI/CD pipeline. Your app builds on GitHub's runners (free tier included), the image is pushed to GHCR, and deployed to your VPS with [zero-downtime blue-green deployment](/features/zero-downtime). Coolify builds on the server by default using Nixpacks or Docker, which means build processes consume your server's CPU and memory. ![Server Compass build configuration showing three build location options: Build on VPS, Build Locally, and Build via GitHub Actions](/app-screenshots/feature-build-config.jpg) ## Templates and One-Click Deploys Both tools offer one-click deployment templates for popular services: - **Server Compass**: [100+ templates](/features/template-deployment) including WordPress, PostgreSQL, Redis, MongoDB, Ghost, Supabase, Minio, Plausible, Uptime Kuma, and more. The [Docker Stack Wizard](/features/docker-stack-wizard) lets you customize templates before deploying. - **Coolify**: 280+ one-click services with a wider catalog, reflecting its larger open-source community. If a specific service you need is only available on one platform, that may drive your decision. You can always [browse Server Compass templates](/templates) to check availability. ## Security Model This is where the architectural difference matters most: - **Server Compass**: Your SSH keys, API tokens, and environment variables are stored in an [encrypted vault](/features/env-vault) on your local machine. They are transmitted to the server only during deployment over SSH. If your server is compromised, attackers don't get your credentials. - **Coolify**: Credentials are stored in a database on the server where the dashboard runs. This is standard for web-based tools, but it means a server breach could expose stored secrets. For solo developers and agencies managing client servers, the local-first security model of Server Compass can be a significant advantage. ## When to Choose Server Compass Go with [Server Compass](/) if: - You want **zero server overhead**—nothing installed on your VPS except Docker. - You want your **credentials to stay on your local machine**, not stored on the server. - You need [100+ deployment templates](/features/template-deployment) to spin up databases, CMS platforms, and monitoring tools in one click. - You want [GitHub Actions CI/CD](/features/github-actions) without writing YAML or configuring pipelines manually. - You're deploying Docker apps with [blue-green zero-downtime deployment](/features/zero-downtime). - You manage **multiple servers** from a single desktop app—unlimited servers, one interface. - You need [database management](/features/db-admin), [.env vault](/features/env-vault), [server backups](/features/server-backups), Docker Compose editing, cron jobs, and server monitoring in one tool. - Budget is tight and you prefer a **one-time $29 purchase** over recurring subscriptions. It's the best option for developers who want a full-featured deployment tool without adding complexity to their servers. ## When to Choose Coolify Choose **Coolify** if: - You need an **open-source, self-hosted dashboard** accessible from any browser on any device. - You want a **web-based UI** that multiple team members can access simultaneously. - You need **Docker Swarm** or more advanced orchestration beyond single-server Docker. - You prefer **community-driven development** and the ability to contribute or extend the platform. - You want the **largest template catalog** (280+ services) available. It's an unbeatable [Heroku alternative](/heroku-alternative) for teams that need a comprehensive, browser-accessible self-hosting platform. If you're also considering other platforms, check out our comparisons for [Render](/render-alternative) and [Fly.io](/flyio-alternative) alternatives. ## Conclusion: Which Self-Hosted Deployment Tool Wins in 2025? Both **Server Compass** and **Coolify** are excellent tools for breaking free from expensive PaaS platforms. The right choice depends on your priorities: - For **zero server overhead, local-first security, and a native desktop experience**: [Server Compass](/) is the clear winner. It keeps your VPS clean, your credentials safe, and gives you 100+ templates, GitHub Actions CI/CD, database management, and unlimited server support for a one-time $29. - For **open-source flexibility, team collaboration, and the widest service catalog**: **Coolify** dominates. Its web dashboard, Swarm support, and 280+ templates make it a powerhouse for teams. The tools aren't mutually exclusive either—some developers use Server Compass for their production servers (where they want minimal overhead) and Coolify for staging or internal tools (where the web dashboard is convenient for the team). Whichever you pick, you'll save hundreds compared to traditional PaaS—welcome to the future of **self-hosted deployments**! Need help setting up your CI/CD pipeline? Try our [GitHub Actions generator](/tools/github-actions-generator) to create workflows without writing YAML manually. Or use the [Dockerfile generator](https://docker.servercompass.app/) to get production-ready container configurations for your stack. --- **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. --- ## Deploy to VPS in 5 minutes (Not 5 hours): Server Compass v1.1.7 Source: https://servercompass.app/blog/deploy-to-vps-in-5-minutes-not-5-hours-server-compass-v117 Published: 2025-11-17 Tags: vercel-alternative, deployment, release New ZIP file deployments, enhanced GitHub integration, bulk env variables, and persistent logs. Get Vercel-like UX on your $5 VPS. You know the drill. You start a new project on Vercel because deployment is effortless. Three months later, you're staring at a $200 monthly bill for what could run on a $5 VPS. You think about migrating, but then you remember the last time you SSH'd into a server and spent two hours debugging nginx configs. If you're tired of these escalating costs, you're not alone — many developers are exploring a [Vercel alternative](/vercel-alternative) that gives them more control. This is exactly why Server Compass exists. And with v1.1.7, we've removed even more friction from VPS deployment. ## The Problem: VPS Management Shouldn't Feel Like Surgery Here's what typically happens when developers try to move from expensive PaaS platforms to affordable VPS hosting: You spend an hour setting up SSH keys. Another hour configuring the server environment. Then you're stuck figuring out how to get your code onto the server without breaking everything. Git clone? SFTP? Some arcane rsync command you found on StackOverflow? When deployment finally works, you have no idea what happened. If it fails, you have even less idea why. The logs are scattered across multiple terminal windows, and you're not even sure if the build succeeded before everything crashed. **This is why 90% of developers stick with expensive PaaS platforms even when they can't afford them.** But there are real alternatives — whether you're looking for a [Railway alternative](/railway-alternative) or a [Heroku alternative](/heroku-alternative), self-hosting on a VPS is now easier than ever. ## What's New in v1.1.7 ![Server Compass deployment history with logs and status badges](/app-screenshots/feature-deploy-history.jpg) We've shipped five major improvements that make VPS deployment feel more like Vercel and less like Linux system administration. ### ZIP File Deployments: Deploy from Anywhere The single biggest pain point we heard from users was deployment flexibility. You have your code on your local machine, and you just want it running on your server. You don't want to commit to GitHub first. You don't want to learn git hooks. You just want to deploy. Now you can. Just compress your project into a ZIP file and upload it. Server Compass handles everything else with [ZIP file deployments](/features/upload-code-deploy): - Download a repository as ZIP from GitHub? Upload it directly - Working on a feature branch locally? Compress and deploy - Want to deploy without committing sensitive files? ZIP your working directory The app automatically names your deployment based on the ZIP file, shows you the file size before uploading, and even installs the unzip tool on your server if it's missing. It works across all major Linux distributions without you thinking about it. Need help generating a Dockerfile for your project? Use our [Dockerfile generator](https://docker.servercompass.app/) to create production-ready configurations. **The hidden complexity it handles:** When you download a ZIP from GitHub, it wraps everything in an extra folder (like `myproject-main/`). Server Compass automatically unwraps this so your app structure stays correct. Your hidden files like `.env` and `.gitignore` are preserved exactly as they should be. ### GitHub Integration That Actually Works Every VPS tool claims "GitHub integration," but most require you to paste tokens into web forms or expose your credentials to third-party services. Our [GitHub integration](/features/github-repo-deploy) takes a different approach. When you connect GitHub for the first time, you now see a clear explanation *before* your computer asks for keychain permission. The app tells you exactly why it needs access: to securely store your GitHub token on your computer, never on external servers. If you accidentally deny access, there's a button to open your system settings and fix it. After you grant permission, the connection continues automatically. No restarting. No re-authenticating. Just seamless setup. **Why this matters:** Your SSH credentials and GitHub tokens never leave your machine. This desktop-first architecture is why Server Compass is more secure than web-based alternatives that require trusting a third party with your infrastructure access. ### Environment Variables: Copy-Paste from Vercel If you've ever migrated a project from Vercel, you know this pain: You have 20 environment variables to transfer. You open Vercel's settings, copy each one individually, paste into your new deployment tool, repeat 19 more times. v1.1.7 adds bulk environment variable pasting. Copy your entire `.env` file, paste it into the [.env Vault](/features/env-vault), and every variable is automatically parsed and validated. The app handles quotes intelligently (whether you use them or not), keeps both the individual and bulk views in sync, and warns you about duplicate keys or invalid formatting. **This alone saves 10 minutes per deployment.** More importantly, it removes the tedious work that causes copy-paste errors in production. ### Deployment Logs: Know What Went Wrong When a deployment fails, you need answers. Not vague error messages. Not "check your server logs." Actual information about what happened and why. Every deployment is now saved with complete logs. Failed deployments show you exactly what went wrong with full error details. You can retry with one click. You can copy logs to your clipboard for debugging. You can adjust how many log lines to keep based on your needs. The [deployment history](/features/deployment-history) shows status badges at a glance (success/failed/running), displays important metadata (branch, commit, port, runtime), and uses color-coded logs to make errors obvious. **Real scenario:** Your build fails because of a missing dependency. Instead of SSH-ing into your server to check what happened, you click "View Logs" in Server Compass. The error is highlighted in red. You add the dependency to your `package.json`, click "Retry," and your app deploys successfully. Total time: 2 minutes instead of 20. ### Terminal That Stays Alive When you're managing multiple servers, you need terminal sessions that persist. Previously, switching between servers or navigating to different tabs would reset your terminal state. You'd lose command history, your working directory, and any running processes. Now your terminal sessions stay alive when you switch contexts. Command history is preserved. Mac [keyboard shortcuts](https://1devtool.com/features/keyboard-shortcuts) work naturally: Cmd+K to clear, Cmd+F to search, Cmd+G to jump between search results. **This seems small until you're debugging three servers simultaneously.** Then it becomes essential. ## Why This Update Matters for Your Business Let's talk numbers. If you're running three production apps on Vercel, you're likely paying $200-300/month. Those same apps run on a $10-20/month VPS without breaking a sweat. **That's $2,400-3,400 per year in savings.** The only reason most developers don't make this switch is deployment complexity. They know VPS hosting is cheaper, but the mental overhead isn't worth the savings. SSH configurations, server management, deployment scripts, log monitoring—it adds up to hours of work per month. Server Compass removes this trade-off. You get VPS-level cost savings with PaaS-level deployment experience. Version 1.1.7 makes this even more true: - **ZIP file deployments** mean you can deploy from anywhere in under 5 minutes - **Persistent deployment logs** mean you debug faster and ship with confidence - **Bulk environment variables** mean migrations take minutes instead of hours - **Enhanced GitHub integration** means setup is painless and secure - **[Persistent terminal sessions](https://1devtool.com/blog/persistent-terminal-sessions-for-coding-guide-2026)** mean you manage servers efficiently ## The Philosophy Behind Server Compass Every feature in v1.1.7 follows the same principle: **Remove friction without sacrificing control.** You still have full SSH access to your servers. You still control your infrastructure. You still choose your hosting provider. But the tedious parts—the ones that make you want to just throw money at Vercel—are handled automatically. This is software that respects your time and your budget. No subscription treadmill. No vendor lock-in. No artificial limitations that force you to upgrade. Just a tool that makes VPS deployment straightforward. ## Get Server Compass Today **Server Compass is $29. One-time payment. No subscription.** You get every feature in v1.1.7, all future updates, and support. It works on Mac, Windows, and Linux. You can manage unlimited servers and deploy unlimited apps. Compare this to Vercel Pro at $240/year, or Railway at $200+/month once you're past their free tier. Server Compass pays for itself with your first month of VPS savings. Plus, with one-click templates for [PostgreSQL](/templates/postgresql), [Redis](/templates/redis), and [MongoDB](/templates/mongodb), you can deploy your entire stack in minutes. [Explore all features](/features) or [watch video tutorials](/tutorials) to see Server Compass in action. **Get Server Compass at [servercompass.app](/)** **Update:** Server Compass has grown significantly since v1.1.7. Current versions include [Docker-based deployments](/features/docker-stack-wizard), [GitHub Actions CI/CD](/features/github-actions), [100+ one-click templates](/features/template-deployment), [database management](/features/db-admin), and much more. [View the full changelog](/changelog). Version 1.1.7 is available now. If you already own Server Compass, just restart the app to download the update automatically. Questions? Email me directly. I respond to every message. *Server Compass is built for developers who want VPS economics without VPS complexity. Deploy faster, debug easier, and stop paying monthly fees for hosting that should cost $5.* --- **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. --- ## Save 5 hours a month: The lazy developer's guide to VPS deployments Source: https://servercompass.app/blog/save-5-hours-a-month-the-lazy-developers-guide-to-vps-deployments Published: 2025-11-16 Tags: vps-deploy, ssh, deployment Tired of typing ssh user@server and running the same 10 commands every time you deploy? This guide shows how to transform your VPS deployment workflow from terminal chaos to visual simplicity. {/\* ------------------------------------------------------------------ \*/} {/\* Introduction \*/} {/\* ------------------------------------------------------------------ \*/} Deploying to a VPS shouldn't feel like a part-time job. Yet for most developers, every deployment is the same ritual: SSH in, pull code, install dependencies, build, restart, cross your fingers, check logs, debug, repeat. Multiply that across staging and production servers, and you're easily burning 5+ hours a month on deployments alone. [Server Compass](/) is a $29 one-time purchase desktop app (Mac, Windows, Linux) that replaces that entire workflow with a visual deployment wizard. Every app runs in a **Docker container** with blue-green deployment for zero downtime. It auto-detects your framework, manages environment variables in an encrypted vault, and can even build your app via GitHub Actions so your low-RAM VPS never breaks a sweat. In this guide, we'll walk through the entire workflow — from connecting your GitHub account to deploying your first app and setting up automatic deployments — so you can be the laziest (and most productive) developer on your team. {/\* ------------------------------------------------------------------ \*/} {/\* Global GitHub Account Management \*/} {/\* ------------------------------------------------------------------ \*/} ## Global GitHub Account Management ### Overview The **Git** tab in the main dashboard provides centralized management of your GitHub accounts across all servers. Think of it as your GitHub identity hub in Server Compass. ### How It Works #### Architecture ``` GitHub OAuth (Device Flow) ↓ Global Account Storage (SQLite) ↓ Link to Multiple Servers ↓ Deploy Apps Using This Account ``` #### Key Features - **OAuth Authentication**: Secure, token-based authentication via the GitHub Device Flow (no passwords stored) - **Multi-Account Support**: Connect multiple GitHub accounts (personal, work, clients) - **Account Summaries**: See which servers use each account and which apps are deployed - **Global Repository Browser**: View all repositories from any connected account ![Server Compass multi-account GitHub management](/app-screenshots/feature-multi-account.jpg) ### Step-by-Step: Connecting GitHub #### Step 1: Navigate to GitHub Accounts 1. Open Server Compass 2. In the main dashboard, click the **Git** tab in the sidebar 3. You'll see the global GitHub accounts management page #### Step 2: Connect Your First GitHub Account 1. Click the **"Connect GitHub Account"** or **"Add Account"** button 2. A modal will appear showing available providers (GitHub is available, GitLab coming soon) 3. Click the **GitHub** card #### Step 3: Complete OAuth Device Flow 1. Server Compass will generate a unique device code (e.g., `ABCD-1234`) 2. A browser tab opens to `https://github.com/login/device` 3. Click "Copy" to copy the code 4. Paste the code in GitHub 5. Authorize the Server Compass application 6. The modal will automatically close once authenticated #### Step 4: View Your Account Once connected, you'll see your account card showing: - **Profile Picture**: Your GitHub avatar - **Account Name/Alias**: Your GitHub name - **Username**: Your @username - **Linked Servers**: How many servers use this account (initially 0) - **Deployed Apps**: Which apps are deployed using this account #### Step 5: Explore Repositories 1. Click on an account card to view its repositories 2. The card will expand to show a "Default" badge 3. Below, you'll see all repositories from this account: - Repository name - Description - Language - Default branch - Private/Public status 4. Use the search bar to filter repositories ![Server Compass repository browser](/app-screenshots/feature-repo-browser.jpg) #### Step 6: Manage Multiple Accounts To add another account: 1. Click "Add Account" in the top right 2. Repeat the OAuth flow 3. Switch between accounts by clicking their cards 4. Set a default account by clicking "Set Default" #### Step 7: Remove an Account 1. Click "Remove" on any account card 2. A confirmation modal appears showing: - Which servers are linked to this account - Which apps are deployed using this account 3. Choose whether to automatically unlink from servers (recommended) 4. Click "Remove Account" to confirm {/\* ------------------------------------------------------------------ \*/} {/\* Server-Specific Git Account Linking \*/} {/\* ------------------------------------------------------------------ \*/} ## Server-Specific Git Account Linking ### Overview Each server has its own **Git** tab where you manage the connection between your global GitHub accounts and that specific server. Before you can deploy from GitHub to a server, you must link a GitHub account to that server. ### Why Link Accounts to Servers? Each server needs its own GitHub authentication because: 1. **Security Isolation**: Different servers may need different access levels 2. **Multi-Tenancy**: One server might use a company account, another a personal account 3. **Access Control**: Production servers might use read-only deploy accounts ### Step-by-Step: Server Linking #### Step 1: Navigate to Server Git Settings 1. From the Servers page, click on a server to open its details 2. Click the Git tab in the server details view 3. You'll see the Git configuration page for this specific server #### Step 2: Link a Global Account to This Server 1. If you haven't connected any GitHub accounts globally yet, you'll see a message prompting you to go to Server Git Settings 2. Click "Link Account" 3. You'll see a list of your global GitHub accounts 4. Select the account you want to use for this server 5. Click "Link to Server" #### Step 3: Set a Default Account (if multiple) If you link multiple accounts to one server: 1. Click "Set as Default" on your preferred account 2. This account will be used automatically when deploying new apps 3. You can still choose a different account during deployment {/\* ------------------------------------------------------------------ \*/} {/\* Deploying Applications \*/} {/\* ------------------------------------------------------------------ \*/} ## Deploying Applications ### Overview Server Compass provides a [Docker Stack Wizard](/features/docker-stack-wizard) that walks you through deploying applications to your servers. Every app runs inside a **Docker container** with blue-green deployment for zero downtime. The wizard supports two deployment paths: 1. **Deploy from GitHub**: Connect a repository, auto-detect the framework, choose a build strategy, and deploy 2. **Deploy a Template**: Pick from [100+ one-click templates](/features/template-deployment) (databases, CMS, monitoring tools, and more) ![Server Compass Docker Stack Wizard](/app-screenshots/feature-stack-wizard.jpg) ### Tutorial: Deploy from GitHub #### Step 1: Start Deployment 1. From the Servers page, click on a server to open its details 2. Click the **Apps** tab in the server details view 3. Click the **"New App"** button to open the Docker Stack Wizard 4. Select **"Deploy from GitHub"** #### Step 2: Select GitHub Account and Repository 1. If you have multiple linked accounts, select the one you want to use 2. Server Compass fetches all repositories from the selected account 3. Use the search bar to filter repositories 4. Click a repository to select it ![Server Compass GitHub repository selection](/app-screenshots/feature-github-deploy.jpg) #### Step 3: Automatic Framework Detection This is where Server Compass saves you the most time. Once you select a repository, [framework detection](/features/framework-detection) kicks in automatically. It analyzes your codebase and detects: - **Framework** — Next.js, React, Vue, Nuxt, Svelte, SvelteKit, Angular, Express, NestJS, Fastify, Django, Flask, FastAPI, Laravel, Go, Rust, Ruby on Rails, and more - **Package manager** — npm, yarn, pnpm, bun, pip, composer, cargo, etc. - **Build command** — auto-suggested based on the detected framework - **Start command** — auto-suggested based on your project's scripts - **Port** — the default port for the detected framework ![Server Compass automatic framework detection for 16+ project types](/app-screenshots/feature-framework-detect.jpg) You can override any of these values, but in most cases the defaults are exactly right. For a standard Next.js app, you typically don't need to change a thing. #### Step 4: Choose Build Location Server Compass gives you three options for where your app gets built. This is especially important if your VPS has limited RAM: 1. **Build on VPS** — The default. Your code is cloned and built directly on the server. Works great for servers with 1GB+ RAM. 2. **Build Locally** — Server Compass builds the Docker image on your local machine, then pushes it to the server. Perfect for low-RAM VPS instances (512MB). 3. **Build with [GitHub Actions](/features/github-actions)** — Offload the build to GitHub's CI/CD runners. Your VPS receives a pre-built Docker image. Zero build load on the server, and you get a full CI/CD pipeline for free. ![Server Compass build configuration with three build location options](/app-screenshots/feature-build-config.jpg) #### Step 5: Configure Deployment Fine-tune your deployment settings: **App Name** — Used as the Docker container name and the directory name on the server. Must be unique per server. **Branch** — Select which Git branch to deploy. ![Server Compass branch selection dropdown](/app-screenshots/feature-branch-select.jpg) **Build Command** — Auto-detected from your framework. Examples: - `npm install && npm run build` (Next.js) - `pip install -r requirements.txt` (Django / Flask) - `composer install --no-dev` (Laravel) - `cargo build --release` (Rust) **Start Command** — Auto-detected from your project. Examples: - `npm start` (Next.js) - `gunicorn app:app` (Flask) - `php artisan serve` (Laravel) - `./target/release/myapp` (Rust) **Port** — Auto-detection finds an available port. Conflict detection warns if the port is already in use by another container, database, or system process. **Environment Variables** — Add key-value pairs directly, or manage them later through the [environment variable vault](/features/env-vault) with AES-256-GCM encryption. ![Server Compass .env Vault with AES-256-GCM encryption](/app-screenshots/feature-env-vault.jpg) #### Step 6: Deploy and Monitor Click **"Deploy Now"** to start deployment. Live log streaming shows real-time deployment progress with color-coded logs. You'll see every step: pulling the repository, building the Docker image, starting the container, and running health checks. ![Server Compass real-time build logs during deployment](/app-screenshots/feature-build-logs.jpg) Your application is now running in a Docker container. Click the URL to open your deployed app. You can view [deployment history](/features/deployment-history), container status, resource usage, and logs at any time from the app dashboard. ### Tutorial: Deploying with Templates Don't have a GitHub repo? Server Compass ships with [100+ one-click templates](/features/template-deployment) for popular software: - **Databases** — PostgreSQL, MySQL, MongoDB, Redis, MariaDB - **CMS** — WordPress, Ghost, Strapi, Directus - **Monitoring** — Uptime Kuma, Grafana, Prometheus - **Dev Tools** — Gitea, n8n, Plausible Analytics, MinIO - **And many more** — [Browse all templates](/templates) ![Server Compass 100+ one-click deployment templates](/app-screenshots/feature-templates.jpg) 1. Choose **"Deploy a Template"** from the Docker Stack Wizard 2. Browse or search templates 3. Configure the app name and any required settings 4. Click **"Deploy"** — templates are pre-configured, so deployment is fast {/\* ------------------------------------------------------------------ \*/} {/\* Understanding Auto-Deploy \*/} {/\* ------------------------------------------------------------------ \*/} ## Understanding Auto-Deploy ### How Auto-Deploy Works [Auto-deploy](/features/auto-deploy) is the feature that makes you truly lazy — in the best way. When enabled, Server Compass watches your GitHub repository for new commits and automatically redeploys your app when changes land on the tracked branch. ### Auto-Deploy Workflow 1. **Initial Deployment**: Repository is cloned, a Docker image is built, and the container starts running 2. **Watching for Changes**: Server Compass monitors the tracked branch for new commits via GitHub push detection 3. **Automatic Redeployment**: When changes are detected — pull latest code, build a new Docker image, perform a blue-green container swap (zero downtime), update the deployment record 4. **Notifications**: Real-time updates in the Server Compass UI with desktop notifications for success or failure ![Server Compass auto-deploy history showing automatic deployments](/app-screenshots/feature-auto-deploy.jpg) ### Blue-Green Deployment Every redeployment uses **Docker blue-green deployment**. Here's what happens under the hood: 1. A new container ("green") is built with the latest code 2. Health checks run on the new container 3. Traffic is switched from the old container ("blue") to the new one 4. The old container is removed Your users never see downtime. If the new container fails its health check, the old container keeps running and you get notified. ### GitHub Actions CI/CD Pipeline If you chose [GitHub Actions](/features/github-actions) as your build location, auto-deploy gets even more powerful. Every push triggers a GitHub Actions workflow that: 1. Builds the Docker image on GitHub's runners (free for public repos, 2,000 minutes/month for private) 2. Pushes the built image to your server 3. Performs the blue-green swap automatically This means your VPS uses zero CPU for builds — it only runs the final container. See our [GitHub Actions CI/CD tutorial](/tutorials/deploy-vps-github-actions-cicd) for a complete walkthrough. ### Benefits of Auto-Deploy **Zero Manual Intervention** — Old way: `ssh`, `cd`, `git pull`, `docker compose build`, `docker compose up -d`, check logs, exit. Server Compass way: `git push origin main`. Done. **Zero Downtime** — Docker blue-green deployment keeps your app running during updates. No dropped requests. **[One-Click Rollback](/features/rollback)** — Every deployment is tracked in [deployment history](/features/deployment-history). If something goes wrong, roll back to any previous version with a single click. ![Server Compass deployment history with logs and rollback](/app-screenshots/feature-deploy-history.jpg) ### Managing Auto-Deploy - View full deployment history with build logs for every deploy - Pause auto-deploy with a toggle switch when you need to freeze deployments - Change the tracked branch from the app settings - Roll back to any previous deployment with one click {/\* ------------------------------------------------------------------ \*/} {/\* Why ServerCompass vs Raw CLI \*/} {/\* ------------------------------------------------------------------ \*/} ## Why Server Compass vs Raw CLI ### The Traditional VPS Workflow (Pain Points) Every manual deployment looks something like this: SSH in, navigate to the project, pull code, install dependencies, build, restart the container (or process), check status, check logs, exit. Time: ~5–10 minutes per deployment. Complexity: 8+ commands. Multiple servers? Double the time and commands. Common problems: 1. **Dependency Hell** — different Node/Python/PHP versions across servers 2. **Port Conflicts** — "address already in use" errors at the worst time 3. **Environment Variables** — manually editing `.env` files over SSH 4. **No Deployment Logs** — did it deploy? Who deployed? When? 5. **No Easy Rollback** — reverting means manual `git reset` and rebuilding 6. **No Isolation** — one app's dependency upgrade breaks another ### The Server Compass Workflow (Solutions) One-click deployment: Open Server Compass, click "New App", select a repository, click "Deploy." Time: 30 seconds. 4 clicks. Solutions for every pain point: 1. **Docker Containerization** — every app runs in its own isolated container with its own dependencies 2. **Port Conflict Detection** — scans all Docker containers, databases, and system processes before deployment 3. **[.env Vault](/features/env-vault)** — visual editor with AES-256-GCM encryption, version history, and team sharing 4. **Live Deployment Logs** — color-coded, searchable, stored in [deployment history](/features/deployment-history) 5. **[One-Click Rollback](/features/rollback)** — revert to any previous deployment instantly 6. **Complete Isolation** — Docker containers prevent dependency conflicts between apps ### Feature Comparison Table Feature Raw CLI Server Compass Initial Setup 1 hour+ 5 minutes Deployment Time 5–10 min/server 30 seconds Multi-Server Deploy 10–20 min 1 minute Containerization Manual Docker setup Automatic (Docker) CI/CD Pipeline Manual GitHub Actions YAML Built-in GitHub Actions Framework Detection Manual config Auto-detect (16+ types) Port Management Manual checking Auto-detection + conflict alerts Environment Variables Manual `.env` editing Encrypted vault (AES-256-GCM) Deployment Logs `docker logs` Live streaming + history Zero-Downtime Deploy Manual blue-green setup Automatic (Docker blue-green) Rollback Manual `git reset` + rebuild One-click Auto-Deploy Manual webhook setup Built-in Templates Copy-paste docker-compose 100+ one-click templates Database Management CLI tools Visual SQL/NoSQL editor Server Backups Manual scripts Scheduled + on-demand GitHub Integration Manual SSH keys OAuth + auto-sync Multi-Account Support Complex SSH config Visual management Branch Selection Manual `git checkout` Dropdown menu Build Command Presets Memorize commands Auto-suggested Error Handling Manual debugging Visual feedback + notifications ### Real-World Scenarios **Scenario 1: Hotfix in Production** Raw CLI: SSH in, pull code, rebuild Docker image, swap containers, check logs — ~10 minutes, 8+ commands. Server Compass: `git push`, auto-deploy triggers, blue-green swap, done. Zero commands. **Scenario 2: Deploy a New Next.js App** Raw CLI: Write a Dockerfile, create docker-compose.yml, configure Nginx, set up SSL, manage environment variables — ~45 minutes. Server Compass: Select repo, framework auto-detected, click Deploy — ~2 minutes. See our [Next.js deployment tutorial](/tutorials/deploy-nextjs). **Scenario 3: Onboarding a New Developer** Raw CLI: ~2 hours explaining server access, Docker workflows, deployment procedures. Server Compass: ~15 minutes — "Click New App, select the repo, click Deploy." **Scenario 4: Managing Multiple Client Projects** Raw CLI: Remembering different servers, credentials, ports, branches, Docker configs. Server Compass: Organized visual server list with per-client GitHub accounts. ### Cost-Benefit Analysis Assuming 20 deployments/month: **Raw CLI**: 20 x 10 min = 200 min + 2 hours troubleshooting = ~5.3 hours/month **Server Compass**: 20 x 0.5 min = 10 min + 15 min troubleshooting = ~25 min/month **Time saved: ~5 hours/month.** At $100/hour, that's $500/month in developer time saved. Server Compass costs **$29 one-time** (no subscription). It pays for itself in the first hour. Error reduction: ~15% deployment failures with CLI vs ~2% with Server Compass (87% fewer failed deployments). Learning curve: Raw CLI 2–4 weeks vs Server Compass 1–2 hours. ### Security Benefits 1. **No Password Storage** — OAuth tokens via GitHub Device Flow, never stored as plain text 2. **Encrypted Environment Variables** — [.env Vault](/features/env-vault) uses AES-256-GCM encryption. Learn more in our [environment variables tutorial](/tutorials/manage-env-variables-env-vault) 3. **Docker Isolation** — each app runs in its own container with isolated networking 4. **Credential Isolation** — each server has its own linked GitHub account with granular access 5. **Server Backups** — scheduled and on-demand backups with one-click restore ### Monitoring and Debugging Benefits 1. **Container Logs** — per-app, filterable, searchable, color-coded live streaming 2. **Deployment History** — visual timeline with build logs and [one-click rollback](/features/rollback) 3. **Health Monitoring** — dashboard with CPU, memory, disk, uptime, and container status 4. **Desktop Notifications** — instant alerts for deployment success, failure, or container crashes {/\* ------------------------------------------------------------------ \*/} {/\* Conclusion \*/} {/\* ------------------------------------------------------------------ \*/} ## Conclusion Server Compass transforms VPS management from a technical chore into a visual, intuitive workflow. Every app runs in a Docker container. Every deployment is tracked. Every environment variable is encrypted. And you never have to SSH into a server to deploy code again. From this (Raw CLI): ``` ssh user@server cd /var/www/myapp git pull origin main docker compose build docker compose up -d docker logs myapp --tail 50 # hope it works exit ``` To this (Server Compass): ``` git push origin main # auto-deploy handles the rest ✓ ``` Key advantages: 1. **90% time reduction** — 30 seconds vs 10 minutes per deployment 2. **87% fewer errors** — automated builds eliminate human mistakes 3. **Docker containerization** — complete app isolation and reproducibility 4. **GitHub Actions CI/CD** — offload builds to GitHub's free runners 5. **16+ framework detection** — auto-configured for your stack 6. **100+ templates** — databases, CMS, dev tools in one click 7. **Zero-downtime deploys** — blue-green container swaps 8. **One-click rollback** — revert any deployment instantly 9. **Encrypted .env Vault** — AES-256-GCM encryption for secrets 10. **$29 one-time** — no monthly subscription, no per-seat pricing Server Compass doesn't just make VPS management easier — it makes it enjoyable. Stop wasting 5 hours a month on deployments. Be lazy. Be productive. **[Try Server Compass](/) — deploy with confidence.** --- ## How to connect your GitHub account and deploy your first Next.js app to your VPS Source: https://servercompass.app/blog/how-to-connect-your-github-account-and-deploy-your-first-nextjs-app-to-your-vps Published: 2025-11-11 Tags: tutorials, nextjs, github, getting-started This guide will walk you through connecting your GitHub account to your Virtual Private Server (VPS) and deploying your first Next.js application using Server Compass. No complex configurations needed. Deploying a Next.js app to your own VPS used to mean hours of SSH commands, Nginx configuration, PM2 setup, and manual Git pulls. Server Compass turns that into a few clicks: connect your GitHub account with OAuth, pick a repo, and deploy — all inside a Docker container with automatic HTTPS and [zero-downtime deployment](/features/zero-downtime). This guide walks you through the entire process, from GitHub authentication to a live production deployment. ## Prerequisites Before you begin, make sure you have: - A VPS added to Server Compass (connected via SSH — see the [server connection tutorial](/tutorials/connect-server-password) if you haven't done this yet) - A GitHub account with a Next.js repository - The Server Compass desktop app installed (Mac, Windows, or Linux) ## Step 1: Connect Your GitHub Account Server Compass uses GitHub's OAuth Device Flow to authenticate your account. There are no Personal Access Tokens to create, no scopes to configure, and no tokens to copy-paste. The entire flow takes about 30 seconds. ### Start the OAuth Flow 1. Open Server Compass and go to the **Git** tab in the main dashboard 2. Click **"Connect GitHub Account"** 3. Select **GitHub** as the provider (GitLab support coming soon) 4. Server Compass generates a unique device code (e.g., `ABCD-1234`) 5. A browser tab opens automatically to `https://github.com/login/device` 6. Copy and paste the device code into the GitHub page 7. Click "Authorize" to grant Server Compass access 8. The modal in Server Compass automatically closes once authenticated ![Server Compass Git tab showing connected GitHub accounts with OAuth device flow authentication](/app-screenshots/5-github.JPEG) That's it. Your GitHub account is now connected to Server Compass. ### Why OAuth Instead of Personal Access Tokens? Earlier versions of Server Compass required you to create a GitHub Personal Access Token (PAT) manually, configure the correct scopes, and paste it in. The OAuth device flow replaces all of that: - **No manual token creation** — no visiting GitHub's token settings page - **No scope configuration** — Server Compass requests exactly the permissions it needs - **Automatic token management** — tokens are refreshed behind the scenes - **More secure** — follows GitHub's recommended authentication flow for desktop apps ## Step 2: Link GitHub Account to Your Server Once your GitHub account is connected globally, you need to link it to the specific server you want to deploy to. 1. Navigate to your server and open the **Git** tab 2. Click **"Link Account"** 3. Select your GitHub account from the list 4. Click **"Link to Server"** This step tells Server Compass which GitHub accounts are authorized to deploy to this particular server. You can link multiple accounts to a single server — useful for agencies managing client repositories or developers with separate personal and work accounts. ## Step 3: Deploy Your Next.js Application Now for the exciting part. Server Compass uses a [Docker Stack Wizard](/features/docker-stack-wizard) that walks you through deployment step by step. Everything runs inside Docker containers — no PM2, no manual process management, no system-level Node.js installs. ### Open the Docker Stack Wizard 1. Navigate to the **Apps** tab on your server 2. Click **"New App"** to open the Docker Stack Wizard 3. Select **"Deploy from GitHub"** 4. Choose your linked GitHub account 5. Search or browse for your Next.js repository 6. Select the branch you want to deploy (usually `main`) ### Automatic Framework Detection Once you select a repository, Server Compass's [framework detection](/features/framework-detection) engine automatically identifies your project's stack: - **Framework:** Next.js (supports [16+ frameworks](/templates) including React, Vue, Nuxt, SvelteKit, Astro, Laravel, Django, Rails, and more) - **Package Manager:** npm, yarn, pnpm, or bun - **Build Command:** detected from your `package.json` scripts - **Start Command:** detected automatically - **Port:** typically 3000 for Next.js ![Server Compass framework detection automatically identifying a Next.js project with package manager, build command, and port](/app-screenshots/feature-framework-detect.jpg) All detected values are pre-filled but fully editable. If Server Compass gets something wrong, you can override any field. ### Choose Your Build Location Server Compass gives you three options for where your Docker image gets built: 1. **Build on VPS** — builds the Docker image directly on your server. Simple and works for most projects, but uses your server's CPU and RAM during builds. 2. **Build Locally** — builds on your machine, then deploys the finished image to the server. Great for heavy builds that would strain a small VPS. 3. **Build with GitHub Actions** — uses a CI/CD pipeline to build on GitHub's infrastructure and deploy automatically. The most robust option for production workflows. See our [GitHub Actions CI/CD guide](/features/github-actions) for details. ![Server Compass build configuration showing build location options: Build on VPS, Build Locally, and Build with GitHub Actions](/app-screenshots/feature-build-config.jpg) ### Add Environment Variables If your Next.js app needs environment variables, add them in the [.env Vault](/features/env-vault) step: `DATABASE_URL=postgresql://user:pass@host/db NEXT_PUBLIC_API_URL=https://api.mysite.com API_SECRET_KEY=your-secret-key` You can paste directly from a `.env` file — Server Compass parses bulk paste input and splits it into individual key-value pairs. Variables like `PORT` and `NODE_ENV` are handled automatically; you don't need to add them. ### Deploy 1. Review your configuration 2. Click **"Deploy"** 3. Watch the live deployment logs Here is what happens behind the scenes when you hit deploy: 1. **Dockerfile generation** — if your repo doesn't already include a Dockerfile, Server Compass generates one optimized for your detected framework 2. **Docker image build** — your application is built inside a Docker container 3. **Blue-green deployment** — the new container starts alongside the old one, traffic switches once the new container is healthy, and the old container is removed ( [zero downtime](/features/zero-downtime)) 4. **HTTPS configuration** — [automatic SSL](/features/auto-ssl) with Let's Encrypt is set up through the Caddy reverse proxy 5. **Reverse proxy setup** — Caddy routes traffic from your domain to the Docker container **Typical deployment time:** 2–5 minutes depending on your app size and server performance. ### Access Your Application Once deployment completes: - **URL:** your app is accessible at your server's IP or configured domain - **Status:** real-time container status in the Apps tab - **Logs:** live container logs for debugging - **Controls:** start, stop, restart, or redeploy with one click ## Step 4: Enable Auto-Deploy (Optional) Want your app to redeploy automatically every time you push to GitHub? Enable [auto-deploy](/features/auto-deploy). ### Toggle Auto-Deploy 1. Go to your deployed app in the Apps tab 2. Navigate to the **Deployments** section 3. Toggle **"Auto-Deploy"** ON 4. Select the branch to watch (e.g., `main`) ### How Auto-Deploy Works When you push to the watched branch, Server Compass automatically: 1. Detects the new commit 2. Pulls the latest code from your repository 3. Builds a new Docker image 4. Performs a [blue-green deployment](/features/zero-downtime) (zero downtime) 5. Updates deployment history with a full log There is no polling or cron job involved. Deployments are triggered by push detection, so your app updates within seconds of a push. ### Alternative: GitHub Actions CI/CD For production workloads that need a more robust pipeline, you can enable GitHub Actions builds instead: - Server Compass generates a complete GitHub Actions workflow for your repository - Builds run on GitHub's infrastructure (no load on your server) - Docker images are pushed to GitHub Container Registry (GHCR) - Your server pulls the built image and deploys automatically [Learn more about GitHub Actions CI/CD](/features/github-actions) ## Troubleshooting ### Problem: "OAuth Authorization Failed" **Solution:** - Make sure you copied the device code correctly — codes are case-sensitive - Check that you authorized the correct GitHub account - If the code expired, close the modal and click "Connect GitHub Account" again to generate a fresh code - Ensure your browser isn't blocking the `github.com/login/device` page ### Problem: "Build Failed" **Solution:** - Check the deployment logs for specific error messages — Server Compass streams the full Docker build output - **Missing environment variables:** add any required variables in the [.env Vault](/features/env-vault) - **Insufficient server memory:** Next.js builds can be memory-intensive. Consider upgrading your VPS or using the "Build Locally" or "Build with GitHub Actions" options to offload the build - **TypeScript errors:** fix locally, push, and redeploy - **Verify locally first:** run `docker build .` on your machine to confirm the build succeeds before deploying ### Problem: "Docker Build Failed" **Solution:** - If you have a custom Dockerfile, ensure it's valid and builds successfully locally - If Server Compass auto-generated the Dockerfile, check that your framework was detected correctly in the wizard. You can edit the Dockerfile from the app settings - Ensure your `.dockerignore` file isn't excluding necessary files (like `package.json` or `next.config.js`) - Check that all dependencies in `package.json` are properly listed — Docker builds start from a clean environment ### Problem: "Port Already in Use" **Solution:** - Choose a different port in the Docker Stack Wizard (e.g., 3001, 3002) - Or stop the conflicting application in the Apps tab ### Problem: "Cannot Access Application After Deployment" **Solution:** - Check that your domain DNS is pointing to your server's IP address - Verify the container is running in the Apps tab (look for a green status indicator) - View container logs for runtime errors - Check your VPS firewall settings — ensure ports 80 and 443 are open for HTTP/HTTPS traffic ## Behind the Scenes ### Docker Container Management Every app deployed through Server Compass runs inside a Docker container. This provides complete isolation between applications, consistent environments between development and production, and easy rollbacks to previous versions. When you deploy, Server Compass: 1. Generates or uses your existing Dockerfile 2. Builds a Docker image tagged with the commit hash 3. Starts a new container alongside the existing one (blue-green deployment) 4. Runs a health check against the new container 5. Switches traffic from the old container to the new one via the Caddy reverse proxy 6. Removes the old container This blue-green approach means your users never see downtime during deployments. ### Security: Credential Encryption Your GitHub OAuth credentials are encrypted using industry-standard encryption: 1. Credentials are encrypted with AES-256-GCM 2. The master key is stored in `/.vault_key` 3. Encrypted credentials are stored in the local SQLite database 4. Decrypted only when needed for Git operations 5. Never exposed to the renderer process or UI ### Multi-Account Architecture - Connect multiple GitHub accounts to Server Compass - Link different accounts to different servers - Switch between accounts per project - Accounts are completely isolated from each other - Ideal for agencies managing multiple client repositories ## Next Steps Your Next.js app is live. Here is what to do next: 1. **Set up a custom domain:** [Configure domain management](/features/domain-management) to point your domain to your app, or follow the [domain + SSL + Cloudflare tutorial](/tutorials/add-domain-ssl-cloudflare-proxy) 2. **Enable HTTPS:** Server Compass can [automatically provision SSL](/features/auto-ssl) certificates with Let's Encrypt 3. **Enable auto-deploy:** toggle it on so pushes to `main` automatically redeploy your app 4. **Deploy more apps:** browse [100+ templates](/templates) for databases, CMS platforms, monitoring tools, and more — or deploy another Git repository using [template deployment](/features/template-deployment) 5. **Watch the video tutorial:** [Next.js deployment video tutorial](/tutorials/deploy-nextjs) covers this entire process in under 5 minutes ## Conclusion You've gone from a GitHub repository to a live, containerized Next.js application running on your own VPS — with OAuth authentication, automatic framework detection, Docker containerization, and optional auto-deploy. No SSH commands, no Nginx config files, no manual process management. What you've learned: - Connecting your GitHub account via OAuth device flow (no PAT tokens needed) - Deploying a Next.js app using the [Docker Stack Wizard](/features/docker-stack-wizard) - Choosing between three build locations: VPS, local, or GitHub Actions - Enabling auto-deploy for continuous deployment from GitHub - Troubleshooting common deployment issues Server Compass makes self-hosted deployment as simple as pushing to GitHub. What used to take hours of manual configuration now takes a few clicks. Ready to get started? [Try Server Compass](/) and deploy your first app today. --- ## Top 7 Vercel Alternatives for Developers in 2025 Source: https://servercompass.app/blog/top-7-vercel-alternatives-for-developers-in-2025 Published: 2025-11-09 Tags: vercel-alternative, deployment, hosting, self-hosted Looking for Vercel alternatives? Discover the best deployment platforms and self-hosted solutions that offer similar developer experience with better pricing, more control, or unique features tailored to your needs. ## Why Look for Vercel Alternatives? Before diving into alternatives, let's understand why developers seek Vercel alternatives: ### Common Pain Points with Vercel - **Pricing Scalability**: Costs can escalate quickly as your traffic grows - **Vendor Lock-in**: Deep integration with Vercel-specific features - **Limited Server Control**: Serverless architecture doesn't fit all use cases - **Bandwidth Costs**: Expensive bandwidth pricing at scale - **Build Minute Limits**: Restrictions on build times and deployment frequency If any of these resonate with you, a [Vercel alternative](/vercel-alternative) might be the right choice. Let's explore the best options available. ## 1\. Server Compass: Self-Hosted Deployment with Vercel UX **Best for**: Developers who want full control without sacrificing developer experience Server Compass takes a unique approach among Vercel alternatives: it gives you the polished deployment experience of Vercel, but on your own VPS infrastructure. With [Docker Stack Wizard](/features/docker-stack-wizard), [GitHub Actions CI/CD](/features/github-actions), and [100+ templates](/features/template-deployment), it's the most comprehensive self-hosted deployment platform available. ### Key Features - **Docker-Based Deployments**: Every app runs in Docker containers with [blue-green deployment](/features/zero-downtime) for zero downtime - **GitHub Actions CI/CD**: Generate complete [GitHub Actions pipelines](/features/github-actions) that build and deploy automatically - **100+ Templates**: Deploy WordPress, PostgreSQL, Redis, MongoDB, Ghost, Supabase, and more with one click — [browse all templates](/templates) - **Framework Detection**: Auto-detects 16+ frameworks (Next.js, Django, Flask, Laravel, Go, Rust, etc.) via [framework detection](/features/framework-detection) - **Three Build Options**: Build on VPS, locally on your machine, or via GitHub Actions - **Own Your Infrastructure**: Deploy to any VPS (DigitalOcean, Hetzner, Linode, etc.) - **Predictable Costs**: Pay only for your VPS ($5-$50/month) — no usage-based pricing - **.env Vault**: AES-256-GCM encrypted [environment variable management](/features/env-vault) - **Database Management**: Deploy and manage PostgreSQL, MySQL, MongoDB, Redis with [built-in database management](/features/db-admin) - **Server Monitoring**: Real-time CPU, memory, disk, and network monitoring - **Domain Management**: Automatic SSL with Let's Encrypt, custom domains - **No Vendor Lock-in**: Standard Docker containers — migrate anytime ![Server Compass build configuration with three deployment options](/app-screenshots/feature-build-config.jpg) ### Pricing - **One-time license**: $29 (lifetime access) - **VPS costs**: $5-$50/month depending on your needs - **Total monthly cost**: As low as $5/month (vs $20-$1000+/month on Vercel) ### Best Use Cases - SaaS applications with growing traffic - Agencies managing multiple client sites - Docker-based deployments with CI/CD - Teams wanting GitHub Actions integration - Projects needing database co-location - Anyone deploying 100+ supported templates - Applications needing WebSockets or long-running processes - Cost-conscious startups and developers ### Potential Drawbacks - Requires basic VPS setup (though Server Compass handles most complexity) - You're responsible for server maintenance - No built-in global edge network (though you can use Cloudflare) Deploy your databases alongside your apps — [PostgreSQL](/templates/postgresql), [MySQL](/templates/mysql), and [Redis](/templates/redis) are all available as one-click templates. Need to generate connection strings? Use our [PostgreSQL connection string builder](/tools/postgresql-connection-string-builder). ## 2\. Netlify: The Original Jamstack Platform **Best for**: Static sites and Jamstack applications Netlify is one of the most established Vercel alternatives, offering similar deployment workflows with some unique features. For a detailed comparison, see our [Netlify alternative](/netlify-alternative) page. ### Key Features - **Git-Based Deployment**: Automatic deployments from Git repositories - **Build Plugins**: Extensive plugin ecosystem - **Split Testing**: Built-in A/B testing capabilities - **Forms and Identity**: Managed form submissions and authentication - **Edge Functions**: Deploy serverless functions globally ### Pricing - **Free tier**: 100GB bandwidth, 300 build minutes/month - **Pro**: $29/user/month - **Enterprise**: Custom pricing ### Why Choose Netlify Over Vercel? - Better free tier for small projects - Built-in form handling and identity management - Strong focus on Jamstack architecture - Excellent documentation and community ### Considerations - Can get expensive at scale (similar to Vercel) - Primarily optimized for static sites - Serverless functions have execution time limits ## 3\. Railway: Modern Infrastructure Made Simple **Best for**: Full-stack applications with databases Railway offers a more traditional hosting approach while maintaining excellent developer experience. Compare it with our [Railway alternative](/railway-alternative) analysis. ### Key Features - **Deploy Anything**: Not limited to serverless -- run any Docker container - **Managed Databases**: PostgreSQL, MySQL, MongoDB, Redis included - **Automatic HTTPS**: SSL certificates managed automatically - **Private Networking**: Services communicate privately - **Usage-Based Pricing**: Pay only for resources consumed ### Pricing - **Free tier**: $5 credit/month - **Developer plan**: Starting at $5/month - **Pay-as-you-go**: $0.000231/GB RAM per minute, $0.10/GB bandwidth ### Why Choose Railway? - Run databases alongside your application - More flexible than pure serverless platforms - Transparent, usage-based pricing - Great for monolithic applications ### Considerations - Still usage-based pricing (though more predictable than Vercel) - Smaller community compared to Vercel/Netlify - Less global edge coverage ## 4\. Render: All-in-One Cloud Platform **Best for**: Teams wanting managed infrastructure without vendor lock-in Render positions itself as a simpler alternative to AWS, with better DX than traditional cloud providers. See our [Render alternative](/render-alternative) for a detailed comparison. ### Key Features - **Web Services**: Deploy from Git with automatic builds - **Static Sites**: Free static site hosting with global CDN - **Cron Jobs**: Scheduled tasks built-in - **Databases**: Managed PostgreSQL and Redis - **Background Workers**: Run background jobs easily ### Pricing - **Static sites**: Free with 100GB bandwidth/month - **Web services**: Starting at $7/month - **Databases**: Starting at $7/month ### Why Choose Render? - Excellent free tier for static sites - Fixed monthly pricing (no surprise bills) - Supports multiple languages and frameworks - Built-in background workers and cron jobs ### Considerations - Build times can be slower than Vercel - Less optimized for Next.js specifically - Smaller ecosystem of integrations ## 5\. Cloudflare Pages: Edge-First Deployment **Best for**: Global applications needing ultra-low latency Cloudflare Pages leverages Cloudflare's massive edge network for blazing-fast performance worldwide. ### Key Features - **Global Edge Network**: Deploy to 275+ data centers - **Unlimited Bandwidth**: No bandwidth costs on any plan - **Workers Integration**: Combine with Cloudflare Workers for dynamic content - **D1 Database**: Edge-native SQL database - **R2 Storage**: Object storage without egress fees ### Pricing - **Free tier**: Unlimited requests and bandwidth, 500 builds/month - **Paid plans**: $20/month (unlimited builds) ### Why Choose Cloudflare Pages? - **Unlimited bandwidth** (huge cost savings) - Unmatched global performance - Generous free tier - Integration with Cloudflare's ecosystem ### Considerations - Best suited for static sites (though Workers add dynamism) - Different mental model than traditional hosting - Edge databases are still maturing ## 6\. DigitalOcean App Platform: Familiar Cloud, Modern DX **Best for**: Developers already using DigitalOcean infrastructure DigitalOcean's App Platform brings platform-as-a-service capabilities to their popular cloud infrastructure. ### Key Features - **Auto-Deploy from Git**: GitHub and GitLab integration - **Multiple Languages**: Node.js, Python, Go, Ruby, PHP, and more - **Managed Databases**: PostgreSQL, MySQL, MongoDB, Redis - **Scalable**: Auto-scaling and load balancing - **Container Support**: Deploy Docker images directly ### Pricing - **Static sites**: $0 (500GB bandwidth included) - **Basic apps**: Starting at $5/month - **Professional apps**: Starting at $12/month ### Why Choose DigitalOcean? - Predictable, straightforward pricing - Part of broader DigitalOcean ecosystem - Good balance of simplicity and control - Excellent documentation ### Considerations - Less focused on frontend frameworks than Vercel - Smaller global network than competitors - Fewer Next.js-specific optimizations ## 7\. Fly.io: Deploy Apps Globally, Run Them Close to Users **Best for**: Applications needing global distribution and edge computing Fly.io takes a unique approach by running full VMs at the edge, closer to your users. Check out our [Fly.io alternative](/flyio-alternative) comparison. ### Key Features - **Global Distribution**: Deploy to 30+ regions worldwide - **Full VM Control**: Not serverless -- actual VMs you control - **Anycast Networking**: Route users to nearest instance automatically - **Persistent Storage**: Volumes that persist across deployments - **PostgreSQL**: Managed Postgres with automatic replication ### Pricing - **Free tier**: 3 shared VMs, 160GB bandwidth - **Pay-as-you-go**: From $0.0000008/second per VM ### Why Choose Fly.io? - True global distribution with state - Full VM control (install anything) - Excellent for WebSocket applications - Great for multi-region databases ### Considerations - Steeper learning curve than Vercel - Configuration requires more infrastructure knowledge - Pricing can be complex to estimate ## Vercel Alternatives Comparison Table Platform Starting Price Best For Bandwidth Costs Server Control **Server Compass** $5/month + $29 license Full control, predictable costs VPS-dependent Full access **Netlify** Free / $29/month Static sites, Jamstack $55/TB overage Limited **Railway** $5/month Full-stack apps with DBs $0.10/GB Medium **Render** Free / $7/month Managed infrastructure Included Medium **Cloudflare Pages** Free / $20/month Global edge deployment Unlimited Limited **DigitalOcean** Free / $5/month Predictable pricing Included Medium **Fly.io** Free / usage-based Global VM distribution $0.02/GB High ## Choosing the Right Vercel Alternative The best Vercel alternative depends on your specific needs: ### Choose Server Compass if: - You want predictable, low costs - You need full server control - You want Docker-based deployments with [zero-downtime](/features/zero-downtime) - You want [GitHub Actions CI/CD](/features/github-actions) without the complexity - You need [100+ one-click templates](/features/template-deployment) - You want [database management](/features/db-admin) built-in - You want encrypted [environment variable management](/features/env-vault) - You're managing multiple projects - You want to avoid vendor lock-in - You need long-running processes or WebSockets ### Choose Netlify if: - You're building primarily static sites - You want built-in form handling - You need A/B testing capabilities - You prefer a mature, established platform ### Choose Railway if: - You need databases co-located with your app - You prefer usage-based pricing with transparency - You're running monolithic applications - You want Docker container flexibility ### Choose Render if: - You want fixed monthly pricing - You need background workers and cron jobs - You prefer simplicity over bleeding-edge features - You want a generous free tier ### Choose Cloudflare Pages if: - Bandwidth costs are your primary concern - You need ultra-low latency globally - You're building edge-first applications - You want unlimited bandwidth ### Choose DigitalOcean App Platform if: - You're already in the DigitalOcean ecosystem - You want straightforward, predictable pricing - You need good documentation and support - You prefer established cloud providers ### Choose Fly.io if: - You need true global distribution with state - You want full VM control at the edge - You're building multi-region applications - You need WebSocket support globally ## Migration Considerations When moving from Vercel to an alternative, consider: ### Technical Migration 1. **Build Configuration**: Most platforms support similar build commands 2. **Environment Variables**: Export and import your env vars 3. **Domains**: Update DNS records (usually 24-48h propagation) 4. **Edge Functions**: May need rewriting for different platforms 5. **Image Optimization**: Alternatives handle this differently ### Testing Your Migration - Deploy to the new platform alongside Vercel initially - Test with a subdomain before switching primary domain - Monitor performance and errors closely - Keep Vercel running until fully confident in migration ### Gradual Migration Strategy 1. **Week 1**: Deploy to alternative platform, test thoroughly 2. **Week 2**: Route 10% of traffic to new platform 3. **Week 3**: Route 50% of traffic if all looks good 4. **Week 4**: Complete migration, decommission Vercel ## Conclusion: The Best Vercel Alternatives for 2025 Vercel is an excellent platform, but it's not the only choice. Whether you're seeking better pricing with Server Compass, unlimited bandwidth with Cloudflare Pages, full-stack capabilities with Railway, or predictable costs with Render, there's a Vercel alternative that fits your needs. The key is understanding your priorities: - **Cost optimization?** Server Compass or Cloudflare Pages - **Simplicity?** Netlify or Render - **Control?** Server Compass or Fly.io - **Full-stack?** Railway or DigitalOcean - **Global edge?** Cloudflare Pages or Fly.io ### Take the Next Step Ready to explore a Vercel alternative? Here's what to do next: 1. **Identify your priorities**: Cost, control, features, or simplicity? 2. **Try the free tier**: Most platforms offer generous free tiers 3. **Deploy a test project**: See how it performs with real code 4. **Compare costs**: Calculate what you'd pay at your current traffic levels 5. **Make the switch**: Migrate when you're confident If you're looking for maximum cost savings with minimal compromise on developer experience, [try Server Compass](/). Deploy Docker containers to your own VPS with GitHub Actions CI/CD, 100+ one-click templates, and encrypted .env management — all for as little as $5/month. Never worry about usage-based billing again. ## Frequently Asked Questions ### Is Vercel still worth it in 2025? Yes, for many use cases. Vercel excels at Next.js deployment, has excellent DX, and if you're on the Hobby tier or have light usage on Pro, it can be cost-effective. However, as you scale, alternatives often provide better value. ### Which Vercel alternative is cheapest? **Server Compass** offers the lowest ongoing costs ($5-$50/month VPS + one-time $29 license). It includes Docker-based deployments, 100+ one-click templates, and GitHub Actions CI/CD — all without usage-based pricing. **Cloudflare Pages** (free tier with unlimited bandwidth) and **Render** (free static sites, $7/month for dynamic apps) are also strong budget options. ### Can I migrate from Vercel without rewriting my app? Most Vercel alternatives support standard Next.js deployments with minimal changes. You may need to adjust Edge Functions and some Vercel-specific APIs, but the core application usually works unchanged. ### Which alternative has the best free tier? **Cloudflare Pages** wins for unlimited bandwidth. **Render** offers free static sites with 100GB bandwidth. **Netlify** provides 100GB and 300 build minutes. **Fly.io** includes 3 free VMs. ### Do these alternatives support Next.js? Yes! All platforms listed support Next.js, though optimization levels vary. Vercel is naturally the most optimized for Next.js (they created it), but others like Netlify, Render, and Server Compass provide excellent support. Server Compass auto-detects 16+ frameworks including Next.js, Django, Flask, Laravel, Go, and Rust — so your project is configured automatically during deployment. ### What about edge computing? **Cloudflare Pages** and **Fly.io** offer the best edge computing capabilities. **Vercel** and **Netlify** also provide edge functions. **Server Compass** can integrate with Cloudflare for edge caching. ### Helpful Tools for Migration Switching platforms is easier with the right tools. Generate your deployment configurations automatically: - [Dockerfile Generator](https://docker.servercompass.app/) — Create production-ready Dockerfiles for any framework - [Nginx Config Generator](/tools/nginx-config-generator) — Generate reverse proxy configurations with SSL - [GitHub Actions Generator](/tools/github-actions-generator) — Build CI/CD pipelines without writing YAML --- **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. 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. --- ## Server Compass vs Vercel: Take Control of Your Infrastructure and Save Thousands Source: https://servercompass.app/blog/server-compass-vs-vercel-take-control-of-your-infrastructure-and-save-thousands Published: 2025-11-09 Tags: vercel-alternative, comparison, self-hosted If you're reading this, chances are you've experienced that sinking feeling when opening your Vercel invoice. What started as a convenient deployment platform has become an increasingly expensive proposition as your application scales. If you're reading this, chances are you've experienced that sinking feeling when opening your Vercel invoice. What started as a convenient deployment platform has become an increasingly expensive proposition as your application scales. A single viral post, a successful product launch, or simply growing your user base can transform your $20/month bill into hundreds or even thousands of dollars overnight. The problem isn't Vercel itself—it's a great platform. The problem is the model: paying for serverless functions, bandwidth, and compute by the drink adds up fast. And while you're paying premium prices, you're also locked into their infrastructure with limited control over how your servers run. Enter **Server Compass**: the self-hosted alternative that gives you full control over your infrastructure while dramatically reducing costs. If you're looking for a [Vercel alternative](/vercel-alternative), this is what thousands of developers are switching to. ## The Real Cost of Convenience Let's break down what you're actually paying for with managed platforms like Vercel: ### Vercel Pricing Reality Check - **Pro Plan:** $20/month per user (minimum) - **Function Executions:** After 1M executions, you pay $0.60 per additional million - **Bandwidth:** After 1TB, you pay $0.40 per additional GB - **Build Minutes:** After 6,000 minutes, you pay for more - **Serverless Function Duration:** Limited to 60 seconds (Pro), 900 seconds (Enterprise) A moderately successful application can easily hit $200-500/month. A high-traffic site? You're looking at $1,000-5,000/month or more. ### Server Compass + Your VPS: A Different Math With Server Compass, you deploy to your own VPS. Here's what that looks like: - **DigitalOcean Droplet:** $12-48/month (4GB-16GB RAM) - **Hetzner Cloud:** $5-30/month (similar specs, European servers) - **Linode:** $12-48/month - **Vultr:** $12-48/month For a **$12-48/month fixed cost**, you get: - Unlimited function executions - Unlimited bandwidth (up to your VPS limits) - Unlimited build minutes - Full control over server configuration - No surprise bills - Ability to run multiple projects on one server **The savings:** If you're spending $200/month on Vercel, switching to a $24/month VPS saves you **$176/month or $2,112/year**. At $500/month, you save **$5,712/year**. At $1,000/month? **$11,712 annually**. ## Beyond Cost: The Control You're Missing Price is just part of the story. With Server Compass, you gain capabilities that managed platforms simply don't offer: ### 1\. True Server Control **With Vercel:** You're limited to serverless functions that run for 10-60 seconds (900 seconds on Enterprise). Want to run a background job? Need WebSockets? Want to host a database on the same server? You're out of luck or paying extra. **With Server Compass:** Your VPS is yours. Run long-running processes, WebSocket servers, databases, cron jobs, background workers—anything you need. Install any software, configure any service, optimize however you want. Deploy [PostgreSQL](/templates/postgresql), [Redis](/templates/redis), or [MongoDB](/templates/mongodb) with one click and manage them alongside your application. ### 2\. No Vendor Lock-In **With Vercel:** Your application is optimized for Vercel's infrastructure. Edge functions, middleware, image optimization—it all ties you deeper into their ecosystem. Migrating becomes increasingly painful as your app grows. **With Server Compass:** Standard Docker containers, standard Node.js/Python/Go applications, standard databases. Your stack is portable. Not happy with your VPS provider? Migrate in an hour. Want to add more servers? Deploy the same Docker images anywhere. ### 3\. Predictable Costs **With Vercel:** You never quite know what next month's bill will be. Got mentioned on Reddit? Your costs just spiked. DDoS attack? You're paying for every malicious request. **With Server Compass:** Your VPS bill is the same every month. Period. The only surprise is when you realize how much money you're saving. ### 4\. Data Privacy and Compliance **With Vercel:** Your data passes through Vercel's infrastructure. Need GDPR compliance with EU-only data storage? Need HIPAA compliance? You're at the mercy of their capabilities. **With Server Compass:** Choose a VPS provider in your required region. Your data never leaves that server. You control access, logging, security, and compliance measures completely. ### 5\. Performance Optimization **With Vercel:** You get their optimizations, which are excellent—but generic. You can't tune database connections, adjust Node.js heap sizes, or implement custom caching strategies at the server level. **With Server Compass:** Optimize everything. Fine-tune Nginx/Caddy configuration using our [Nginx config generator](/tools/nginx-config-generator), implement Redis caching exactly how you want, adjust database connection pools, profile and optimize at the OS level. Need a reverse proxy setup? Generate it in seconds. ## Real-World Scenarios: When Server Compass Wins ### Scenario 1: The Growing SaaS You've built a SaaS application that's gaining traction. You have 500 active users generating consistent traffic. **Vercel costs:** - Pro plan: $20/month - Function executions: ~$30/month - Bandwidth overages: ~$80/month - **Total:** ~$130/month **Server Compass costs:** - DigitalOcean 8GB Droplet: $48/month - **Total:** $48/month **Savings:** $82/month ($984/year) Plus, you can run your PostgreSQL database on the same server, saving another $15-30/month from managed database costs. ### Scenario 2: The Agency You manage 10 client websites. On Vercel, each needs its own project, and costs add up. **Vercel costs:** - 10 projects x $20 (Pro plan minimum) = $200/month - Bandwidth and functions across all sites: ~$150/month - **Total:** ~$350/month **Server Compass costs:** - One beefy VPS (16GB): $48/month - All 10 sites running on one server - **Total:** $48/month **Savings:** $302/month ($3,624/year) ### Scenario 3: The Startup You're pre-revenue but growing fast. Every dollar counts. **Vercel costs:** - Starting at $20/month, but as you gain users: $100-200/month **Server Compass costs:** - Small VPS: $12/month - Scale up to $24/month as you grow **Savings:** $88-188/month when you need it most That's money you can put into marketing, hiring, or extending your runway. ## What About the Developer Experience? "But Vercel's DX is amazing!" you say. "I just `git push` and it deploys!" You're right—and Server Compass doesn't ask you to give that up. With Server Compass, you get: - **Git-based deployments:** Push to your repo, [auto-deploy](/features/auto-deploy) to your VPS - **Zero-downtime deployments:** [Blue-green deployments](/features/zero-downtime) built in - **Automatic HTTPS:** Let's Encrypt certificates auto-renewed - **Environment management:** Manage env vars through a beautiful UI with [.env Vault](/features/env-vault) — AES-256-GCM encrypted - **Health monitoring:** Know immediately if something goes wrong - **Rollback capabilities:** One-click rollback to previous versions - **Docker-based deployments:** Every app runs in containers with automatic Dockerfile generation via the [Docker Stack Wizard](/features/docker-stack-wizard) - **GitHub Actions CI/CD:** Generate complete build pipelines — build on VPS, locally, or via GitHub Actions. [See the CI/CD tutorial](/tutorials/deploy-vps-github-actions-cicd) - **100+ templates:** Deploy databases, CMS platforms, and more with one click. [Browse templates](/templates) - **Framework detection:** Auto-detects 16+ frameworks and configures builds automatically - **Database management:** Deploy and manage PostgreSQL, MySQL, MongoDB, Redis alongside your apps ![Server Compass container management with CPU and memory monitoring](/app-screenshots/feature-container-controls.jpg) The deployment experience is just as smooth—you've just removed the middleman and the markup. [Watch the Next.js deployment tutorial](/tutorials/deploy-nextjs) to see it in action. ## Making the Switch: Easier Than You Think Moving from Vercel to Server Compass isn't as daunting as it sounds: 1. **Spin up a VPS:** DigitalOcean, Hetzner, Linode—take your pick ($12-48/month) 2. **Download Server Compass:** Install the desktop app on Mac, Windows, or Linux 3. **Connect your repository:** Same Git repo, different destination 4. **Deploy:** Server Compass handles Docker builds, container orchestration, and automatic Dockerfile generation for your framework 5. **Point your DNS:** Update your A record to your VPS IP 6. **Done:** You're self-hosted with full control Most migrations take 1-2 hours. The return on that time investment? Thousands of dollars annually. ## When Vercel Still Makes Sense To be fair, Vercel isn't wrong for everyone: - **You're building a small side project:** If you're under their free tier limits, stick with Vercel - **You have zero DevOps knowledge and zero interest in learning:** Managed platforms make sense - **You need edge functions globally distributed:** Vercel's edge network is excellent - **You're a large enterprise with specific support needs:** Enterprise support has value But if you're: - A startup watching every dollar - An agency managing multiple clients - A developer who wants to learn infrastructure - A SaaS growing beyond hobby-project scale - Anyone tired of surprise bills Server Compass gives you the control and cost-efficiency you need. Check out how we compare to other platforms: [Railway alternative](/railway-alternative), [Render alternative](/render-alternative), and [Netlify alternative](/netlify-alternative). ## The Bottom Line **Vercel is renting an apartment:** Convenient, but expensive, and you're always at the landlord's mercy. **Server Compass is owning your home:** More responsibility, but far more affordable, and it's truly yours. For most developers and businesses, the math is simple: - Save $2,000-10,000+ annually - Gain complete infrastructure control - Eliminate vendor lock-in - Deploy unlimited projects on one server - Scale predictably The question isn't whether you can afford to switch to Server Compass. It's whether you can afford to keep paying Vercel's premium. Ready to take control of your infrastructure and stop the bleeding? [Try Server Compass today](/) and see how much you'll save. ## Getting Started with Server Compass 1. Visit [Server Compass](/) 2. Follow the 5-minute installation guide 3. Deploy your first application 4. Watch your hosting costs drop by 80-95% Your future CFO will thank you. Get started faster with our free tools: [Dockerfile generator](https://docker.servercompass.app/) and [GitHub Actions generator](/tools/github-actions-generator) for automated CI/CD pipelines. --- **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.