# Leaving Vercel: moving a Next.js app to a Hostinger VPS URL: https://www.savemores.store/vps/vercel-to-hostinger-vps Author: Mr. Ahmed · Published 2026-10-03 · Updated 2026-10-03 · VPS & deployment ## Short answer - Most of Next.js works unchanged under next start on a VPS, including Image Optimization, ISR and middleware. - Vercel Cron Jobs become crontab entries that call the same route with a secret; Vercel Analytics and Speed Insights must be removed or replaced. - Pull production env vars with the Vercel CLI, drop the VERCEL_* ones, and set NEXT_PUBLIC_* variables before running next build. - Lower DNS TTL to 300 seconds a day before, switch the A record, and keep the Vercel project running for a couple of days so nobody hits a dead site. - You give up per-PR preview URLs, one-click rollback and the edge network in exchange for a flat monthly bill and no function timeouts. ## Should you leave at all? Vercel is very good at what it does, especially for a team that depends on per-branch previews and has no interest in running a server. People tend to leave for one of three reasons: the bill grew with traffic or seats, a function ran into a timeout or size limit, or they want the database and background jobs on the same machine as the app. If one of those describes you, a VPS such as Hostinger's KVM 1 (4 GB RAM; from $4.99/mo on a 48-month term, or Rs 2,099/mo on 24 months on the Pakistan store) runs most Next.js apps for a fixed monthly price. If none of them do, staying on Vercel is a perfectly reasonable decision. > From the bench: Moving off a platform is a trade of money for responsibility. You will be the one patching the server. If that sentence makes you uneasy, stay where you are; the boring choice is usually right. ## Build the server before touching DNS Get the VPS fully working first. The [Next.js on a Hostinger VPS guide](https://www.savemores.store/vps/deploy-nextjs) covers Node 24, standalone output, PM2 and Nginx; this article only deals with what's different when the app is coming from Vercel. Lock the box down with the [new VPS security checklist](https://www.savemores.store/vps/secure-new-vps) at the same time. Do all of it against the server's IP address. The Vercel deployment stays live throughout. ## Environment variables Vercel keeps env vars per environment. Pull the production set with the CLI, review it, and copy it to the server. Strip anything Vercel injected automatically (`VERCEL_*`); the app shouldn't rely on those once it's off the platform. On your laptop, inside the linked project: ```bash npx vercel env pull .env.production --environment=production # Inspect it, delete VERCEL_* lines, then copy it up scp .env.production deploy@YOUR_SERVER_IP:/home/deploy/app/.env.production ``` > From the bench: `NEXT_PUBLIC_*` values are compiled into the client bundle at build time. If they aren't on the server before `next build` runs, the browser code ships with them undefined, and you'll spend an hour wondering why. ## Vercel features, and what replaces them Under `next start`, most of Next.js behaves the same. These are the parts that need a decision: | On Vercel | On your VPS | | --- | --- | | Image Optimization | Works under `next start`. Make sure `sharp` is installed; standalone builds pick it up automatically. | | ISR / revalidate | Works. The cache lives on disk in `.next`, which is fine for a single server. | | Middleware / proxy | Works, in the same Node process. | | Vercel Cron Jobs | Replace with a crontab entry calling the same route (below). | | Vercel Postgres / KV / Blob | Hosted services. Keep using them over the network, or move to Postgres or Redis on the VPS. | | @vercel/analytics, Speed Insights | Vercel-only. Remove them, or switch to Plausible, Umami or GA4. | | Preview deployments | Not included. Keep Vercel for previews if the team needs them. | ## Replacing Vercel Cron Each entry in the `crons` block of `vercel.json` is just a scheduled GET to a route. Do the same with cron on the server, and protect the route with a secret so nobody else can trigger it. `crontab -e` as the deploy user. Runs /api/cron/daily at 03:00 server time: ```bash 0 3 * * * curl -fsS -H "Authorization: Bearer $CRON_SECRET" https://yourdomain.com/api/cron/daily > /dev/null ``` > From the bench: Cron does not read your `.env` file. Define `CRON_SECRET=...` at the top of the crontab, or call a small script that sources the env file first. A cron job that silently 401s every night is worse than no cron job, because you think it's working. ## Test with the real domain, before DNS moves You can hit the new server using the real hostname without changing DNS for anyone else. `curl --resolve` sends the request to the VPS IP while keeping your domain in the request: - Point your hosts file at the VPS and click through the main pages. - Submit a form, log in, and trigger the cron route once by hand. - Watch `pm2 logs` for errors while you do it. ```bash curl -I --resolve yourdomain.com:80:YOUR_SERVER_IP http://yourdomain.com/ ``` ## The DNS switch, without downtime A day ahead, drop the TTL on your A and CNAME records to 300 seconds so the change spreads quickly. On the day, point the A record at the VPS IP. Once it resolves to the new server, run Certbot (or let Caddy) issue the HTTPS certificate. Keep the Vercel project running for a couple of days so visitors with cached DNS still reach a working site. When Vercel's dashboard shows traffic at zero, remove the domain from the project. The [DNS pointing guide](https://www.savemores.store/vps/point-domain-dns) has the record details. 1. Day before: set TTL on A/CNAME records to 300 seconds. 2. Switch day: change the A record to the VPS IP. 3. Once it resolves: issue the HTTPS certificate with Certbot or Caddy. 4. Two or so days later: when Vercel traffic is zero, remove the domain from the Vercel project. > From the bench: If you used Vercel's nameservers, move DNS to your registrar or Hostinger first and recreate every record, MX, TXT and verification records included, before changing the A record. A missing MX record is how email breaks during a migration without anyone noticing for a week. ## What you give up, and what you get To be straight about it: no preview URL per pull request, no instant rollback button (you `git checkout` the previous commit and redeploy), and no global edge network unless you put Cloudflare in front. You also become the person who applies security updates. What you get back is a fixed monthly bill, no function timeouts, and one machine that can run the app, its database, workers and your side projects together. If that trade suits you, WEBHOST2026 applies to Hostinger VPS plans through this site; see the [Hostinger VPS review](https://www.savemores.store/vps/hostinger-vps-review) for the longer verdict. ## FAQ ### Does Next.js Image Optimization work off Vercel? Yes. It works under next start on a VPS as long as sharp is installed, and standalone builds pick sharp up automatically. ### What replaces Vercel Cron Jobs on a VPS? A crontab entry that calls the same route on a schedule, protected by a secret in an Authorization header. Remember that cron does not load your .env file. ### Can I move from Vercel without downtime? Yes. Test the VPS with curl --resolve, lower DNS TTL a day ahead, switch the A record, and keep the Vercel project live for a couple of days while cached DNS expires. ### What will I lose by leaving Vercel? Per-pull-request preview URLs, the one-click rollback button and the built-in edge network. You also take on server maintenance and security updates yourself.