vpsFocus
From Vercel to your own VPS: what you lose and how to get it back
Many projects start on Vercel or Netlify: connect the repository, and the site is live. Then comes a bill for bandwidth or functions, you hit the limits, you want your database next to your code. And the project moves to a VPS: a fixed price, no limits on execution time, everything under your control.
The move itself usually goes smoothly: the site runs within an evening, especially with Coolify, Dokploy or Kamal. The trouble starts later. The platform did a lot of work for you that you never saw, and on your own server that work hasn't gone anywhere — it's just that nobody is doing it now.
Here's exactly what you lose and what to replace it with.
At a glance
| What the platform did | What's on you now | What to use |
|---|---|---|
| HTTPS | issuing and renewing the certificate | Caddy or certbot + an expiry check |
| Deploys from git | building, shipping, rolling back | Coolify, Dokploy, Kamal |
| CDN | caching and serving static files worldwide | Cloudflare in front of the server |
| Analytics | counting visits | Umami or Plausible on your own server |
| Logs | storage and rotation | journald, logrotate, Docker log limits |
| Availability | the server not going down | an external check + alerts |
| Cron | scheduled jobs | cron or systemd timers + a job watchdog |
| Database | backups and restores | backups off the server |
| Security | servers and updates | firewall, updates, key-only login |
Each point in detail below.
1. HTTPS
On the platform the certificate appeared and renewed by itself. On a VPS your web server issues it: Caddy does this automatically, with nginx it's usually certbot. Renewal is automatic too — until it breaks: you changed the config, closed port 80, moved behind Cloudflare.
What to do: test the renewal (sudo certbot renew --dry-run if you use certbot) and set up a certificate expiry check that writes to you a couple of weeks before the end.
2. Deploys and rollbacks
git push → the site is updated, and if something breaks there's a “roll back to the previous version” button. On a VPS without a tool, deploying is ssh, git pull, npm run build, a restart and a prayer.
What to do: install Coolify or Dokploy (similar to Vercel, with a panel and deploys from git) or Kamal (from the console, no panel). The main thing they give back is zero-downtime builds and a one-command rollback.
Note: a panel like Coolify becomes part of the server itself, something you have to update and protect. Its address shouldn't be open to everyone with the default password.
3. CDN
The platform served static files from servers all over the world. Your VPS sits in one city, and a visitor on another continent waits longer.
What to do: put Cloudflare in front of the server — the free plan caches static files and hides the server's address. Afterwards, check that the certificate still renews: Cloudflare changes how the server is seen from outside.
4. Analytics
Vercel Analytics and Speed Insights were one checkbox away. On a VPS they don't exist.
What to do: put analytics on the same server — Umami or Plausible. The data stays with you, and you won't need cookies. More in “Self-hosted analytics on your own server instead of Google Analytics”. Page speed (Core Web Vitals) can be checked with Google's free PageSpeed Insights.
5. Logs
On the platform, logs were in the dashboard and disappeared by themselves after a few days. On a VPS they pile up. Docker logs are not limited in size by default — after a couple of months a chatty app fills the whole disk with them, and the site goes down.
What to do: limit Docker logs. In /etc/docker/daemon.json:
{
"log-driver": "json-file",
"log-opts": { "max-size": "10m", "max-file": "3" }
}Restart Docker after the change. The limit applies to containers created afterwards: existing ones need to be recreated. And look at free disk space now and then: df -h.
6. Availability
This is the biggest thing you lose. The platform ran dozens of servers: one goes down, another takes over. Your VPS is one machine. Memory runs out, the disk fills up, the host reboots the machine — the site is down until you notice.
What to do: an external check that opens your site every minute and writes to you when it doesn't respond. It has to check from outside: a server that's down can't report on itself. And keep an eye on the server itself — disk, memory, CPU — to see trouble before the site goes down.
One more thing: the app process should come back by itself after a crash and after a server reboot. In Docker that's restart: unless-stopped, in systemd Restart=always.
7. Scheduled jobs
Vercel Cron called your endpoint on schedule, and the dashboard showed whether a run went through. On a VPS it's cron or a systemd timer — and if a job stops running, you won't find out. Nightly emails, a sync, a database backup silently don't happen for weeks.
What to do: after each run the job sends a short signal to an outside service (“I'm done”). If the signal doesn't arrive on time, you get an email. These services are called job watchdogs (heartbeat monitoring, or a dead man's switch).
8. Database and backups
If you used a managed database (Vercel Postgres, Neon, Supabase), it made backups by itself. Once the database moves to your VPS, backups are your job.
What to do:
- a scheduled database backup (
pg_dumpfor PostgreSQL,mysqldumpfor MySQL); - store backups somewhere other than the same server — object storage or another machine;
- make sure backups actually happen (see point 7) and haven't suddenly shrunk to half the size;
- try restoring from a backup at least once.
9. Server security
On the platform the server wasn't yours, and it was protected for you. Now you have a real Linux machine with SSH open, and it will be scanned within the first hour.
What to do: key-only login instead of a password, a firewall, automatic security updates, database ports on 127.0.0.1 only. The full list with commands is in “Your site is live on a VPS. What to check next”.
Is the move worth it
Yes, if the project is hitting the platform's limits or price and you have an hour a week for the server. Your own VPS gives you a predictable bill, a database next to your code, and the freedom to run anything.
No, if the whole project is a landing page with a couple of pages and the free plan is enough: the platform will do more for you than the move would save.
How vpsFocus does this
vpsFocus is a free desktop app that brings back to your VPS part of what the platform gave you. You add a server over SSH, and it installs analytics and monitoring on it without touching your site:
- analytics (Umami) on your server — sources, pages, countries, devices, people coming from ChatGPT and Perplexity answers;
- server health — disk, memory, CPU, failed services and containers; an email when something goes wrong — one, not one every minute;
- certificate and domain expiry — a reminder in advance;
- site errors from the web server logs, page speed and an SEO audit;
- a backup of the analytics database into an archive on your computer.
Two features work through the vpsFocus server and need an account, because they can't be done from the VPS itself: checking availability from outside and a job watchdog for cron. Everything else is free, with no account and no limit on the number of sites and servers.