DEV Community: Vishvajeet Shukla

PM2 vs systemd for Node.js in Production: Which Should You Use? (2026)

Vishvajeet Shukla — Tue, 03 Nov 2026 14:14:48 +0000

Every Node.js app on a VPS needs something to start it, restart it when it crashes and bring it back after a reboot. The two common answers are PM2 and systemd. Both work. They're good at different things.

Quick answer

PM2 if you want cluster mode, pm2 reload with no dropped requests, and friendly per-app commands.
systemd if you want zero extra dependencies, strict sandboxing and the same tool you use for every other service.

What each one is

systemd is the init system on almost every modern Linux distro. It already runs Nginx, SSH and cron. A Node app becomes one more unit file.

PM2 is a Node.js process manager installed via npm. It runs its own daemon, which manages your apps and is itself started by systemd through pm2 startup. ShipOwn's guide What Is PM2? covers it in depth.

Side by side

	PM2	systemd
Install	`npm i -g pm2`	Built in
Auto-restart on crash	Yes	`Restart=always`
Start on boot	`pm2 startup` + `pm2 save`	`systemctl enable`
Cluster mode across CPU cores	Built in	You run multiple units or use Node's cluster module
Zero-downtime reload	`pm2 reload`	Not out of the box
Logs	`~/.pm2/logs`, `pm2 logs`	journald, `journalctl -u`
Log rotation	`pm2-logrotate` module	journald handles it
Memory limit restart	`max_memory_restart`	`MemoryMax=` (kills), plus `Restart=`
Sandboxing	Minimal	Strong (`ProtectSystem`, `NoNewPrivileges`...)
Monitoring view	`pm2 monit`	`systemctl status`, external tools

A minimal systemd unit

[Unit]
Description=My Node API
After=network.target

[Service]
User=deploy
WorkingDirectory=/srv/api/current
EnvironmentFile=/srv/api/shared/.env
ExecStart=/usr/bin/node dist/main.js
Restart=always
RestartSec=3
NoNewPrivileges=true
ProtectSystem=full

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload && sudo systemctl enable --now api

ShipOwn's free systemd service file generator builds one of these in your browser.

A minimal PM2 setup

module.exports = { apps: [{
  name: 'api', script: 'dist/main.js', cwd: '/srv/api/current',
  instances: 'max', exec_mode: 'cluster', max_memory_restart: '400M'
}]};

pm2 start ecosystem.config.js && pm2 save && pm2 startup

When PM2 is the better choice

You run several Node apps on one server and want one consistent set of commands.
You want to use all CPU cores without writing cluster code.
You deploy often and want pm2 reload to roll workers without dropping requests.

When systemd is the better choice

You run a single service and don't want another daemon or global npm package.
Security hardening matters and you want systemd's sandbox options.
Your team already manages everything with systemctl and journald.

Mistakes with either

Running as root. Use a deploy user in both cases.
Forgetting reboot persistence. pm2 save after changes; systemctl enable for units. Test with a real reboot.
Unbounded logs. Install pm2-logrotate, or check journald's SystemMaxUse.
Env changes not applied. pm2 reload --update-env, or systemctl restart after editing the EnvironmentFile.

My choice

For Node apps I deploy often, I use PM2, mainly for reloads and cluster mode. It's also what ShipOwn, the desktop app I built for deploying to servers you already own, uses for Node apps: Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify and Express run under PM2, and you can see PM2 processes next to CPU, RAM, disk and a live terminal in the health view. For a single small internal service, a systemd unit is hard to beat.

Written by Vishvajeet Shukla, full stack developer and founder of ShipOwn.

502 Bad Gateway After a Deploy? How to Debug and Roll Back on a VPS (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:40:08 +0000

You deploy, refresh the page and see 502 Bad Gateway. Users are hitting it too. The worst thing you can do now is start changing things at random over SSH.

This post is a playbook: first get the site back (rollback), then find the cause (debugging), then prevent it next time. Along the way I'll show how ShipOwn handles each step on servers you own.

What a 502 actually means

Nginx is up and received the request, but when it forwarded the request to your app (the "upstream"), it got no valid response. So the problem is almost always between Nginx and the app, not DNS or HTTPS.

Typical causes:

The app process crashed or never started.
The app listens on a different port than Nginx expects.
The app is still starting (slow boot) or stuck.
The server ran out of memory or disk.
A Docker container is bound to a different interface or port.

Step 0: Restore service first

If the site worked before this deploy, roll back before you debug. Users don't care why; they care that it works.

Manual rollback

If you deploy into release folders with a current symlink:

cd /var/www/app
ls releases/                       # find the previous release
ln -sfn releases/20261027-1830 current
pm2 reload app

If you deploy in place with git pull, rollback means checking out the previous commit and rebuilding, which is slow and stressful mid-incident. That alone is a good reason to switch to release folders.

Rollback with ShipOwn

ShipOwn puts every deploy in its own release directory and only moves the live pointer after the build and health check pass. If a deploy fails those checks, the previous release is restored automatically. If the problem appears later, you can switch back to a retained release from the app's operate page (or to an earlier image for Docker apps), while its files are still on the server.

Step 1: Is the app running?

pm2 status
pm2 logs app --lines 100

Look for errored, a climbing restart count, or a stack trace. Common culprits after a deploy: a missing environment variable, a failed build that left no output, or a dependency that didn't install.

For Docker:

docker ps -a
docker logs --tail 100 <container>

Step 2: Is it on the right port?

sudo ss -ltnp | grep -E '3000|8000'
grep -R proxy_pass /etc/nginx/sites-enabled/

The port in proxy_pass must match what the app actually listens on. A changed PORT variable is a classic cause.

Test the app directly, bypassing Nginx:

curl -I http://127.0.0.1:3000

If that works, the problem is Nginx config. If it fails, it's the app.

Step 3: Check the Nginx error log

sudo tail -n 50 /var/log/nginx/error.log

connect() failed (111: Connection refused) means nothing is listening. upstream timed out means the app is too slow or stuck.

Step 4: Check resources

free -h
df -h
uptime
dmesg | grep -i -E 'killed process|oom'

A full disk breaks builds and logs. An out-of-memory kill silently stops your app. Both are common on small VPS plans.

Step 5: Fix, then redeploy

Once you know the cause, fix it in the code or config and deploy again. Not by editing files on the live server, or your next deploy will overwrite the fix.

Debugging with an approval-based AI terminal

Mid-incident, remembering the right command is the hard part. ShipOwn includes an AI terminal for exactly this moment:

You describe the problem in plain language: "the site returns 502 since the last deploy".
Using your own Anthropic, OpenAI or DeepSeek API key, the model inspects the server and proposes one shell command at a time, with its reason.
You approve each command before it runs.
Destructive commands (recursive deletes, reboots, firewall flushes, stopping SSH) are always held for confirmation.

The AI never runs on ShipOwn's servers. Requests go from your computer to the provider you chose, and your key is encrypted by the OS. Prompts and command output do go to that provider, so check output for secrets before sharing.

Next to it, ShipOwn's server view shows CPU, RAM, disk, load average and PM2 processes, read directly from the server, plus an embedded terminal and logs. You can usually spot the out-of-memory or full-disk case at a glance.

Prevent the next 502

Release directories + health checks. Don't switch traffic until the new version answers.
Test Nginx before reload. ShipOwn tests every config it writes and restores it if Nginx rejects it.
Build where there's memory. ShipOwn's PC build mode builds on your machine and uploads the verified output.
Set restart policies. PM2 or restart: unless-stopped for containers.
Get told when it's down. ShipOwn's tray heartbeats report an "unreachable" incident after two consecutive failures, and report recovery once (while the app is running and your PC is awake).
Know what's live. ShipOwn shows the commit each app runs and how far behind its branch it is.

One honest limit: no deploy tool rolls back your database. If a release ran a migration, you need a separate plan for migrations and backups.

Quick reference

Symptom	First command
502 right after deploy	Roll back, then `pm2 logs`
`Connection refused` in Nginx log	`ss -ltnp` to check the port
`upstream timed out`	App logs, `uptime`, slow queries
App randomly dies	`dmesg` for OOM kills
Build fails	`df -h`, `free -h`

Conclusion

A 502 is stressful but predictable. Roll back first, then check the process, the port, the Nginx log and the server's resources. If you want release-based rollback and approval-gated AI debugging on your own VPS, try ShipOwn free for 30 days, no card required.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

ShipOwn vs Coolify vs CapRover vs Dokploy: Which Self-Hosted Deploy Tool Fits You? (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:40:01 +0000

If you want Heroku- or Vercel-style deploys on your own server, four names come up again and again: Coolify, CapRover, Dokploy and ShipOwn. They solve the same problem, getting your app from a repo to a live URL on hardware you control, but they make very different design choices.

Full disclosure: I built ShipOwn. I'll stick to architecture and documented behaviour, and say plainly where the other tools are the better pick. Feature lists change fast, so check each project's docs before deciding.

The one difference that matters most

Coolify, CapRover and Dokploy are platforms you install on the server. A web dashboard and its supporting services run on your VPS, and your apps are deployed as Docker containers.

ShipOwn is a desktop app. It runs on your Windows, macOS or Linux computer and connects to the server over plain SSH. No ShipOwn deployment agent is installed on the server. The server stays a normal Linux box running PM2, Nginx and, only if you want it, Docker.

Almost every other difference follows from this.

Side-by-side

	Coolify	CapRover	Dokploy	ShipOwn
Where it runs	On your server	On your server	On your server	On your computer
Interface	Web dashboard	Web dashboard + CLI	Web dashboard	Desktop app
Apps run as	Docker containers	Docker containers (Swarm)	Docker containers	PM2 (Node), Nginx (static) or Docker
Docker required	Yes	Yes	Yes	No (optional)
Source code	Open source	Open source	Open source	Commercial, closed source
Auto-deploy on push	Yes (webhooks)	Yes (webhooks)	Yes (webhooks)	No, manual deploy with "commits waiting" indicator
Team access via browser	Yes	Yes	Yes	No, per-device desktop licence

Coolify

Coolify is a popular open-source, self-hostable PaaS. Install it on a server and you get a web dashboard to deploy apps from Git, run databases and services, and manage multiple servers.

Choose Coolify if: you want a browser dashboard your whole team can use, you're happy with everything in Docker, and you like the open-source model and community.

Consider: the platform itself uses CPU, memory and disk on your server, and it's another piece of software on the server you need to keep updated.

CapRover

CapRover is one of the older open-source options. It runs on Docker Swarm, offers a web UI and CLI, and has a catalogue of one-click apps.

Choose CapRover if: you want something battle-tested, simple captain-definition deploys, or a multi-node Swarm cluster.

Consider: everything is containerised, and Swarm adds concepts you may not need on a single small VPS.

Dokploy

Dokploy is a newer open-source platform with a modern UI, strong Docker and Docker Compose support, and database management.

Choose Dokploy if: you live in Compose files and want a clean, modern dashboard on the server.

Consider: like Coolify, it's a control plane running next to your apps.

ShipOwn

ShipOwn brings the platform workflow to your desktop:

Connect a server over SSH (tested before it's saved).
Pick a source: a GitHub repo and branch, or a local folder.
Review the plan: framework, commands, port, domain and target, all editable.
Watch it build on the server, or on your PC with the verified output uploaded.
Operate it: live URL, deployed commit, health, logs, redeploy, rollback.

It deploys three kinds of apps:

Node apps under PM2: Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify, Express.
Static sites on Nginx: Vite (React/Vue), Astro, plain HTML.
Docker apps from a Dockerfile or Compose file, with commit-labelled images and the previous container kept until the health check passes.

Other documented features: Nginx virtual hosts tested before reload and restored if rejected, Certbot HTTPS with expiry shown, a release directory per deploy with automatic restore on failure, server vitals read from /proc and pm2 jlist, an embedded terminal, file browser, fail2ban setup, management of existing containers, and an AI terminal that uses your own Anthropic, OpenAI or DeepSeek key and proposes one command at a time for your approval.

Choose ShipOwn if: you want nothing extra running on the server, you deploy Node apps without Docker, you build on your own machine to spare a small VPS, or you want approval-gated AI help for server problems.

Consider: there's no auto-deploy on push, no browser dashboard for a team, and it's a commercial product, not open source. It uses a hosted licence service and update service, so it isn't fully offline.

Decision guide

"My team needs a shared web dashboard." → Coolify or Dokploy.
"I want everything containerised, maybe across nodes." → CapRover or Dokploy.
"I need auto-deploy on every push." → Coolify, CapRover or Dokploy.
"I want my server to run only my apps, no platform." → ShipOwn.
"My Next.js app runs fine on PM2; I don't want Docker." → ShipOwn.
"I want open source." → Coolify, CapRover or Dokploy.

Can you combine them?

Partly. ShipOwn can inspect and manage Docker containers that are already on a server, but running two deployment systems against the same apps will cause confusion. Pick one owner per app.

FAQ

Which one is the "best"? None in general. The architecture question (dashboard on the server vs app on your desktop) usually decides it.

Which is lightest on the server? ShipOwn adds no platform process to the server; the others run their dashboard and services there.

Can I try ShipOwn without paying? Yes, a free 30-day trial with no card. Check the supported environments first.

Conclusion

Coolify, CapRover and Dokploy are excellent open-source platforms if you want a dashboard and containers on the server. ShipOwn is for developers who'd rather keep the server plain and drive deploys from their own machine. Try the one whose architecture fits how you work, and if that's the desktop approach, start with ShipOwn.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

How to Cut Hosting Costs by Self-Hosting Your Apps on a VPS (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:37:32 +0000

Managed platforms are priced per app, per seat, per build minute or per gigabyte of bandwidth. That's fair when you have one big app. It adds up fast when you're a freelancer or a small team running ten small ones: client sites, internal tools, side projects, staging copies.

A single Linux VPS can often host all of them. This guide explains how to work out whether self-hosting actually saves you money, how to consolidate apps safely, and where tools like ShipOwn reduce the time cost that usually eats the savings.

We won't quote prices here because they change constantly and depend on your region and usage. Use your own invoices for the maths below.

Step 1: Audit what you pay for today

Make a simple table from your last three invoices:

App	Platform	Monthly cost	Traffic	Needs always-on?
Client site A	PaaS	…	low	yes
Internal tool	PaaS	…	very low	no
API	PaaS + DB add-on	…	medium	yes

Look for:

Per-app minimums on apps that get almost no traffic.
Add-ons (databases, Redis, logging) priced separately.
Seat-based pricing for people who only deploy occasionally.
Bandwidth or function-invocation overages.

Step 2: Size one server for the whole group

Low-traffic Node apps under PM2 and static sites served by Nginx use little memory when idle. A static site uses no process at all, since Nginx serves files directly. That's why consolidation works.

Rough method:

Check each app's memory in production (pm2 status or the platform's metrics).
Add them up, plus headroom for builds (builds are the memory spike, not runtime).
Add the database if you plan to host it on the same server (many people keep a managed DB instead).
Pick a plan with comfortable margin. Resizing a VPS later is usually easy.

Tip: if builds are the bottleneck, build on your own machine and upload the output. ShipOwn's PC build mode does exactly this, so a small server only has to run the app.

Step 3: Count the hidden cost: your time

Self-hosting isn't free. You now own:

OS updates and security patches
Nginx configs and HTTPS renewals
Process restarts and crash recovery
Rollback when a deploy breaks
Monitoring and "is it down?" checks
Backups, especially for databases

If those take you several hours a month, compare that time to what you'd save. This is the line that decides whether self-hosting is cheaper, and it's where automation matters most.

Step 4: Consolidate safely

Give every app its own domain and port

client-a.example.com  → Nginx → 127.0.0.1:3001 (PM2)
tool.example.com      → Nginx → 127.0.0.1:3002 (PM2)
www.example.com       → Nginx → /var/www/site (static)
api.example.com       → Nginx → 127.0.0.1:8000 (Docker)

Isolate failures

One bad Nginx config can break every site. Test before every reload.
One app leaking memory can starve the others. Set PM2 max_memory_restart or container memory limits.
Keep releases separate so rolling back app A doesn't touch app B.

Watch the shared resources

Disk fills up from logs, old builds and Docker images. Check CPU, RAM, disk and load regularly.

Step 5: Migrate one app at a time

Deploy the app to the VPS on a temporary subdomain.
Test it, including env vars and webhooks.
Lower the DNS TTL, then switch the real domain.
Keep the old platform running for a few days.
Cancel the old plan only when you're confident.

How ShipOwn lowers the time cost

ShipOwn is a desktop app for Windows, macOS and Linux that deploys and operates apps on Linux servers you own, over plain SSH, without installing a deployment agent on the server. It targets the maintenance tasks listed in Step 3:

Deploys Node apps under PM2 (Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify, Express), static sites on Nginx (Vite, Astro, plain HTML) and Docker/Compose apps, through one five-step flow: connect, pick source, review plan, watch build, operate.
Nginx and HTTPS: writes virtual hosts, tests before reload, restores a rejected config, requests Certbot certificates and shows expiry.
Rollback: each deploy has its own release directory, a failed deploy restores the previous release automatically, and you can switch back to a retained release later.
Monitoring: CPU, RAM, disk, load and PM2 processes read directly from the server, plus tray heartbeats that report an "unreachable" incident after two consecutive failures (while the app runs and your PC is awake).
Security basics: fail2ban can be installed and viewed from the app.
Debugging: an AI terminal using your own Anthropic, OpenAI or DeepSeek key proposes one command at a time for your approval.

It also shows which commit each app runs and how far behind its branch it is, which is handy when you have many small apps on one box.

What it doesn't do: auto-deploy on push, and it doesn't replace a backup plan for your databases.

When self-hosting is not cheaper

You have one app that fits a free or low tier already.
You rely heavily on platform features like preview deployments or a global edge network.
Nobody on the team is willing to own the server.

FAQ

Can I keep my database managed and self-host only the apps? Yes, and for many teams that's the best balance.

How many apps can one VPS run? It depends on memory and traffic. Measure, then size with headroom.

Is ShipOwn free? It starts with a free 30-day trial, no card required, then paid plans.

Conclusion

Self-hosting saves money when you consolidate several small apps and keep the maintenance time low. Measure your real costs, size one server sensibly, migrate one app at a time, and let ShipOwn handle the repetitive deploy, HTTPS and rollback work.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

Custom Domain + Free SSL on a VPS: Nginx and Certbot Done Right (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:37:19 +0000

Your app is running on the server. curl localhost:3000 works. Now you want https://app.example.com with a padlock, and that last mile (DNS, Nginx, certificates, renewals) is where a surprising number of deploys go wrong.

This guide covers custom domains and free HTTPS on a Linux VPS end to end, plus how ShipOwn automates it safely.

How the pieces fit

DNS maps app.example.com to your server's IP.
Nginx listens on ports 80/443 and decides which app gets each request, based on the server_name.
Certbot proves to Let's Encrypt that you control the domain and installs a certificate into Nginx.
Renewal replaces the certificate before it expires.

Step 1: DNS records

At your domain registrar or DNS provider:

Type	Name	Value
A	`app`	your server's IPv4
AAAA	`app`	your server's IPv6 (only if Nginx listens on IPv6)
A	`@`	server IP (for the root domain, if needed)
CNAME	`www`	`example.com`

Check propagation before going further:

dig +short app.example.com

If it doesn't return your IP yet, Certbot will fail. Wait.

If you use Cloudflare's proxy (orange cloud), set it to DNS-only while you issue the certificate, or use Cloudflare's own certificates with "Full (strict)".

Step 2: Open the firewall

sudo ufw allow 'Nginx Full'

Also check your cloud provider's firewall or security group: ports 80 and 443 must be open.

Step 3: An Nginx server block

# /etc/nginx/sites-available/app.example.com
server {
  listen 80;
  listen [::]:80;
  server_name app.example.com;

  location / {
    proxy_pass http://127.0.0.1:3000;
    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 Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

For a static site, use root /var/www/site; and try_files instead of proxy_pass.

Step 4: Test before you reload. Always.

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Nginx serves every site on the server from one process. If you reload a broken config, you can take down all of them. nginx -t is the cheapest insurance in DevOps.

Step 5: Issue the certificate

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com

Certbot answers the HTTP challenge, edits your server block to add listen 443 ssl, certificate paths and (optionally) an HTTP→HTTPS redirect.

Multiple names on one certificate:

sudo certbot --nginx -d example.com -d www.example.com

Step 6: Renewals

Let's Encrypt certificates are short-lived, so renewal must be automatic. The Certbot package usually installs a systemd timer. Verify it:

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

Bonus: www vs non-www and HTTP to HTTPS

Pick one canonical host and redirect the other. Search engines treat example.com and www.example.com as different URLs, so serving the same content on both splits your signals.

server {
  listen 443 ssl;
  server_name www.example.com;
  # ssl_certificate lines added by Certbot
  return 301 https://example.com$request_uri;
}

server {
  listen 80;
  server_name example.com www.example.com;
  return 301 https://example.com$request_uri;
}

Also check that your app generates absolute URLs (sitemaps, Open Graph tags, OAuth callbacks) with the final HTTPS host. Many "redirect loop" and "OAuth mismatch" bugs after a domain change come from an old BASE_URL or NEXTAUTH_URL environment variable, not from Nginx.

Quick verification checklist

curl -I http://app.example.com returns a 301 to HTTPS.
curl -I https://app.example.com returns 200 from your app.
sudo certbot certificates lists the domain with a future expiry date.
sudo nginx -t is clean.

Common mistakes

DNS not propagated yet → challenge fails. Check with dig.
Port 80 blocked → the HTTP challenge can't reach you.
Two server blocks with the same server_name → Nginx warns and picks one; requests go to the wrong app.
Forgot X-Forwarded-Proto → the app thinks it's on HTTP and creates redirect loops.
Renewal silently failing → you find out when browsers show a warning. Check expiry regularly.

Domains and HTTPS with ShipOwn

ShipOwn is a desktop app (Windows, macOS, Linux) that deploys apps to your Linux server over SSH, with no deployment agent installed on the server. Domains and HTTPS are built into the deploy flow:

When you point a domain at an app or static site, ShipOwn writes the Nginx virtual host for it.
It tests the configuration before reloading Nginx.
If Nginx rejects the config, it's put back the way it was, so one app's domain can't break the others.
It asks Certbot for a certificate when you want HTTPS.
Certificate expiry is shown in the app, so a failing renewal doesn't stay hidden.

The domain is part of the deploy plan you review before anything runs, next to the framework, commands, port and target. Every value is editable.

ShipOwn also helps when the server moves: if a server's IP changes, it traces the server through its own domains and confirms it by its SSH host key.

FAQ

Do I need a paid SSL certificate? No. Let's Encrypt certificates are free and trusted by all major browsers.

Can I host several domains on one VPS? Yes. Each gets its own server block; Nginx routes by server_name.

Does ShipOwn change my existing Nginx sites? It writes virtual hosts for the apps you deploy with it and tests every change before reloading.

Conclusion

DNS, a clean server block, nginx -t, Certbot and working renewals: that's all custom-domain HTTPS really is. Do it carefully once, and let ShipOwn repeat it for every app with the safety checks built in. Free 30-day trial, no card needed.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

Docker Deploy Without a DevOps Engineer: Dockerfile to Live HTTPS in 6 Steps (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:34:52 +0000

"It works in Docker on my laptop" is a great start. Getting that container onto a real server, behind a domain, with HTTPS and a way back when an update breaks, is where many small teams stall. Usually because nobody on the team is "the DevOps person".

You don't need one for a single server. This guide takes a Dockerfile or Compose project from your repo to a live HTTPS URL in six steps, explains the parts people get wrong, and then shows how ShipOwn automates the same path from a desktop app.

Why Docker on a VPS at all?

Any language. Python, Go, Rust, PHP, Ruby, Java and .NET apps all run the same way once they're in a container.
Same environment everywhere. The image you test is the image you run.
Clean server. Dependencies live in the image, not on the host.

If your app is plain Node.js, you may not need Docker at all; PM2 is lighter. Docker earns its place when you have non-Node services or several services wired together with Compose.

Step 1: Install Docker properly

On Ubuntu, install Docker Engine and the Compose plugin from Docker's official repository (or with the convenience script for a quick test):

curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER   # log out and in again
docker compose version

Step 2: Build on the server

git clone https://github.com/you/service.git && cd service
docker compose build

Tag images with the commit you built from, so you always know what's running:

docker build -t service:$(git rev-parse --short HEAD) .

Step 3: Bind to localhost, not the world

This is the most common Docker-on-VPS mistake. ports: "8000:8000" publishes the port on every interface, and Docker's own firewall rules can bypass ufw. Bind to loopback instead and let Nginx be the only public entry:

services:
  web:
    build: .
    restart: unless-stopped
    ports:
      - "127.0.0.1:8000:8000"
    env_file: .env
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      retries: 3

Step 4: Start it and check health

docker compose up -d
docker compose ps        # look for "healthy"
docker compose logs -f web

restart: unless-stopped brings the container back after a crash or reboot.

Step 5: Nginx and HTTPS

server {
  server_name service.example.com;
  location / {
    proxy_pass http://127.0.0.1:8000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d service.example.com

Step 6: Update safely and keep a way back

The risky update is git pull && docker compose up -d --build on a live service. If the new image starts but is broken, you're down until you fix it.

A safer pattern:

Build the new image with a new tag.
Start it alongside the old one on a different localhost port.
Wait for its health check to pass.
Switch Nginx to the new port, nginx -t, reload.
Keep the old image for a quick rollback.

It works, but it's a lot of steps to repeat by hand.

Doing it with ShipOwn

ShipOwn is a desktop app for Windows, macOS and Linux that deploys over plain SSH. No ShipOwn deployment agent is installed on the server. For Docker apps it follows the safe pattern above:

Builds your Dockerfile or Compose file on the server.
Labels images with the commit they came from.
Routes through Nginx to 127.0.0.1 when configured.
Keeps the previous container until the health check passes.
Lets you go back to an earlier image later.

The deploy flow is the same as for every ShipOwn app: connect a server, pick a GitHub branch or local folder, review an editable plan, watch the build stream live, then operate it from one page. If the server has no Docker yet, ShipOwn can install it for you.

Managing containers you already have

ShipOwn also works with containers already running on the server. It inspects every container, maps published and internal ports, shows CPU and memory gauges, calls out crash loops, and gives you start, stop and restart, a shell inside the container, and its logs.

Domains and certificates

Point a domain at the app and ShipOwn writes the Nginx virtual host, tests it before reloading, restores it if Nginx rejects it, and asks Certbot for a certificate. Certificate expiry is shown in the app.

Troubleshooting checklist

Symptom	Likely cause
Container restarts in a loop	App crashes on start; read `docker logs`
502 from Nginx	Wrong port, or container bound to a different interface
Service reachable on `IP:8000` from the internet	Port published on `0.0.0.0` instead of `127.0.0.1`
Disk full	Old images and build cache; `docker system prune` with care
Env vars missing	`.env` not loaded or wrong `env_file` path

Stuck on something else? ShipOwn's AI terminal uses your own Anthropic, OpenAI or DeepSeek key to propose one command at a time, with its reason. You approve each one, and destructive commands always wait for confirmation.

FAQ

Does ShipOwn use Kubernetes or Swarm? No. It builds and runs containers on a single Linux server you control.

Is Docker required for every app? No. Node apps run under PM2 and static sites are served by Nginx without Docker.

Is ShipOwn open source? No, it's a commercial app. What runs on your server is plain SSH and shell commands.

Conclusion

You don't need a DevOps engineer to run containers on a VPS. You need localhost-bound ports, Nginx, HTTPS, health checks and a rollback plan. Learn the steps above, then let ShipOwn run them for you. Free 30-day trial, no card.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

Deploy Any Web App on a DigitalOcean Droplet: Node, Static or Docker (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:34:39 +0000

Most deploy tutorials cover one kind of app. Real servers rarely stay that tidy. A single DigitalOcean Droplet often ends up hosting a Node API, a static marketing site and a container or two.

This guide shows how to deploy all three on one Droplet, each on its own domain with HTTPS. Then we'll look at how ShipOwn handles the same mix from a desktop app.

Step 1: Create the Droplet

Create → Droplets, choose a region near your users.
Image: Ubuntu LTS.
Size: a basic plan is enough to start; you can resize later.
Authentication: SSH key (not a password).
Optional: enable the free Cloud Firewall with inbound 22, 80 and 443.

Point three DNS records at the Droplet's IP, for example:

api.example.com for the Node API
www.example.com for the static site
tools.example.com for the Docker app

Step 2: Base setup

ssh root@DROPLET_IP
adduser deploy && usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy
apt update && apt install -y nginx git certbot python3-certbot-nginx
ufw allow OpenSSH && ufw allow 'Nginx Full' && ufw enable

App 1: Node API under PM2

su - deploy
git clone https://github.com/you/api.git && cd api
npm ci && npm run build
PORT=3001 pm2 start npm --name api -- start
pm2 save && pm2 startup

Nginx (/etc/nginx/sites-available/api):

server {
  server_name api.example.com;
  location / { proxy_pass http://127.0.0.1:3001; proxy_set_header Host $host; }
}

App 2: Static site on Nginx

A Vite, Astro or plain HTML site doesn't need a running process at all. Build it and let Nginx serve the files:

git clone https://github.com/you/site.git && cd site
npm ci && npm run build          # outputs dist/
sudo mkdir -p /var/www/site && sudo cp -r dist/* /var/www/site/

server {
  server_name www.example.com;
  root /var/www/site;
  index index.html;
  location / { try_files $uri $uri/ /index.html; }
}

No port, nothing to restart.

App 3: A Docker app

For anything not built on Node (a Python, Go or PHP service, for example), a container is the cleanest route.

curl -fsSL https://get.docker.com | sh
git clone https://github.com/you/tool.git && cd tool
docker compose up -d --build

Bind the container to localhost only, so it isn't exposed directly:

ports:
  - "127.0.0.1:8080:8080"

server {
  server_name tools.example.com;
  location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; }
}

Step 3: Enable sites and HTTPS

sudo ln -s /etc/nginx/sites-available/{api,site,tools} /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d api.example.com -d www.example.com -d tools.example.com

That's three apps, three runtimes, three Nginx files and one certificate run. Now imagine updating each of them every week and rolling back when one breaks.

The same Droplet with ShipOwn

ShipOwn is a desktop app for Windows, macOS and Linux that deploys to Linux servers over SSH. It installs no deployment agent on your Droplet, and it supports exactly these three targets:

Node apps run by PM2: Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify and plain Express, with port, health check and restart policy set.
Static sites served by Nginx: Vite with React or Vue, Astro, or plain HTML, published to a release directory. No process, no port.
Docker apps: a Dockerfile or Compose file built on the server and published behind Nginx. Images are labelled with the commit they came from, and the previous container is kept until the health check passes.

For each app you go through the same five steps: connect server, pick source, review the editable plan, watch the build, operate. Domains and HTTPS work the same way for all three. ShipOwn writes the virtual host, tests it before reloading, restores it if Nginx rejects it, and requests a Certbot certificate.

Managing existing containers

If the Droplet already runs containers you started by hand, ShipOwn can still help. It inspects each container, maps published and internal ports, shows CPU and memory, flags crash loops, and lets you start, stop or restart a container, open a shell inside it and read its logs.

Keeping a mixed server healthy

Watch disk. Docker images and old builds add up. docker system df and du -sh are your friends. ShipOwn's server view shows disk usage at a glance.
One Nginx mistake affects everything. Always nginx -t before reload. ShipOwn does this automatically.
Know what's deployed. ShipOwn shows which commit each app runs and how far behind its branch it is.

Rolling back on a mixed server

Each app type rolls back differently when you do it by hand:

Node app: check out the previous commit, rebuild and pm2 reload. That takes minutes, and the app is in a half-built state while it runs.
Static site: keep the previous dist/ folder around and copy it back.
Docker app: keep the previous image tag and run it again.

ShipOwn gives all three the same model. Every deploy goes into its own release directory (or an image labelled with its commit, for Docker). The live pointer only moves after the build and health check pass. A deploy that fails restores the previous release by itself, and you can go back to a retained release later with one click. Database migrations and persistent data still need their own backup and recovery plan, whichever tool you use.

FAQ

Can ShipOwn deploy a Python or Go app? Through Docker, yes. There's no native Python or Go runtime; ship it in a container.

Does ShipOwn need Docker on the server? Only for Docker apps. Node and static apps run without it, and ShipOwn can install Docker for you if you need it.

Is there a free trial? Yes, 30 days, no card required.

Conclusion

One Droplet can comfortably host an API, a static site and a container. Doing it by hand teaches you how the pieces fit. Doing it every week is where ShipOwn saves time and mistakes.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

Deploy a Web App on AWS EC2 Without DevOps Headaches (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:32:03 +0000

AWS EC2 gives you a virtual server in a huge cloud. That's the good news. The bad news: before your app serves a single request, you're dealing with key pairs, security groups, IP addresses that change on stop and start, and a default user that isn't root.

This guide cuts through it. We'll launch an EC2 instance, deploy a Node.js or Next.js app with PM2 and Nginx, add HTTPS, and then show how ShipOwn turns repeat deploys into a short desktop flow.

Step 1: Launch the instance

In the EC2 console, Launch instance:

AMI: Ubuntu Server LTS (the default user is ubuntu).
Instance type: a small general-purpose type is fine for most side projects. Small instances can run out of memory during builds; more on that below.
Key pair: create or choose one and download the .pem file. You won't get it again.
Network settings / Security group: allow SSH (22) from your IP only, and HTTP (80) and HTTPS (443) from anywhere.
Storage: give yourself enough disk for node_modules, builds and logs.

Step 2: Give it a stable IP

A normal public IP changes when the instance is stopped and started. Allocate an Elastic IP and associate it with the instance, then point your domain's A record at it.

Step 3: Connect

chmod 400 my-key.pem
ssh -i my-key.pem ubuntu@ELASTIC_IP
sudo apt update && sudo apt upgrade -y

Step 4: Install the runtime

sudo apt install -y git nginx
# Node.js LTS via NodeSource or nvm
sudo npm i -g pm2

Add swap on small instances. next build and large TypeScript builds can be killed for lack of RAM:

sudo fallocate -l 2G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Step 5: Deploy the app

git clone https://github.com/you/app.git && cd app
cp .env.example .env
npm ci && npm run build
pm2 start npm --name app -- start
pm2 save && pm2 startup

Step 6: Nginx and HTTPS

server {
  server_name app.example.com;
  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
  }
}

sudo nginx -t && sudo systemctl reload nginx
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d app.example.com

If Certbot can't validate, the usual cause on AWS is the security group: port 80 must be open to the internet for the HTTP challenge.

The AWS-specific gotchas

Problem	Cause	Fix
SSH times out	Security group doesn't allow 22 from your current IP	Update the inbound rule
Site works, then dies after a stop/start	Public IP changed	Use an Elastic IP
`Permission denied (publickey)`	Wrong user or key	Use `ubuntu@` for Ubuntu AMIs and the right `.pem`
Build killed	Not enough RAM	Add swap or build elsewhere
502 Bad Gateway	App not on the expected port	`pm2 logs`, check the port

Repeat deploys with ShipOwn

Launching the instance is a one-time job. Deploying, updating, adding domains and rolling back happen again and again. That's where ShipOwn helps.

ShipOwn is a desktop app for Windows, macOS and Linux. It connects to your EC2 instance over plain SSH, using the same .pem key and ubuntu user. No ShipOwn deployment agent is installed on the instance.

The flow:

Connect a server: Elastic IP, port 22, user ubuntu, your key. ShipOwn tests the connection before saving it.
Pick a source: GitHub repo and branch, or a local folder.
Review the plan: detected framework, commands, port, domain and target. Every value is editable, and nothing runs until you approve.
Watch it build: choose a server build, or a PC build that builds on your computer and uploads the verified output. That's handy on a small instance that struggles with next build.
Operate it: live URL, deployed commit, how far behind its branch it is, health, logs, redeploy and rollback.

What ShipOwn takes care of:

Node apps under PM2: Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify, Express.
Static sites on Nginx: Vite (React/Vue), Astro, plain HTML.
Docker apps from a Dockerfile or Compose file. It can also install Docker on a server that doesn't have it.
Nginx config tested before reload, and restored if rejected.
Certbot HTTPS, with certificate expiry shown in the app.
Release directories and rollback: the live pointer only moves after the build and health check pass.

Monitoring without CloudWatch setup

For a single instance, you might not want to set up a full metrics stack. ShipOwn's server view shows CPU, RAM, disk, load and PM2 processes, read directly from /proc and pm2 jlist, next to an embedded terminal. Heartbeats can run from the system tray while the app is running and your PC is awake.

When something breaks

Describe the problem to ShipOwn's AI terminal ("the site returns 502 since the last deploy"). Using your own Anthropic, OpenAI or DeepSeek key, it inspects the server and proposes one command at a time with its reason. You approve each one. Destructive commands (recursive deletes, reboots, firewall flushes, stopping SSH) are always held for confirmation.

FAQ

Does ShipOwn manage AWS resources like security groups? No. You create the instance in AWS. ShipOwn works over SSH once the server exists.

Can I use Amazon Linux? ShipOwn handles Ubuntu, Debian, the RHEL family and Alpine. See the supported environments page before choosing.

Auto-deploy on push? Not in ShipOwn. It shows waiting commits, and you click deploy.

Conclusion

EC2 is powerful but has a few traps: security groups, changing IPs, small-instance memory. Get those right once, then use ShipOwn for the deploy-and-rollback loop. Try ShipOwn free for 30 days, no card required.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

How to Deploy a Node.js App on Hetzner Cloud (2026 Guide)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:31:55 +0000

Hetzner Cloud is a favourite with developers who want a plain Linux server without a big cloud console in the way. You create a server, get an IP, and SSH in. Everything after that is up to you.

This guide walks through deploying a Node.js app (Express, NestJS, Fastify or similar) to a Hetzner Cloud server, from the first SSH login to HTTPS on your domain. At the end, we'll do the same deploy with ShipOwn to show which parts can be automated.

What you'll build

A hardened Ubuntu server on Hetzner Cloud
Your Node.js app running under PM2
Nginx proxying your domain to the app
A free Let's Encrypt certificate
A simple way to roll back

Step 1: Create the server

In the Hetzner Cloud console:

Create a project, then Add Server.
Pick a location close to your users.
Choose Ubuntu (a current LTS release) as the image.
Pick a small shared-vCPU plan to start. You can resize later.
Add your SSH public key here. Don't rely on the root password email.
Create a Firewall that allows inbound TCP 22, 80 and 443 only, and attach it.

Copy the server's public IPv4 address.

Step 2: First login and a deploy user

ssh root@SERVER_IP
apt update && apt upgrade -y
adduser deploy
usermod -aG sudo deploy
rsync --archive --chown=deploy:deploy ~/.ssh /home/deploy

Now test ssh deploy@SERVER_IP in a new terminal before going further. Then disable password logins in /etc/ssh/sshd_config (PasswordAuthentication no) and restart SSH.

Optional but useful: install fail2ban so repeated failed logins get banned.

sudo apt install -y fail2ban

Step 3: Install Node.js, Git and PM2

sudo apt install -y git nginx
# install Node.js LTS via NodeSource or nvm
sudo npm i -g pm2

Step 4: Get your code onto the server

cd ~
git clone https://github.com/you/api.git
cd api
cp .env.example .env    # set PORT=3000 and secrets
npm ci
npm run build            # if you use TypeScript or NestJS

Step 5: Start with PM2

pm2 start dist/main.js --name api    # or: pm2 start npm --name api -- start
pm2 save
pm2 startup                          # run the command it prints

pm2 logs api shows output; pm2 status shows uptime and restarts.

Step 6: Nginx reverse proxy

Create /etc/nginx/sites-available/api:

server {
  listen 80;
  server_name api.example.com;
  client_max_body_size 10m;
  location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}

sudo ln -s /etc/nginx/sites-available/api /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Always run nginx -t first. A typo in one file can stop Nginx serving every site on the server.

Step 7: DNS and HTTPS

Point an A record for api.example.com to the Hetzner IP. Once it resolves:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d api.example.com

Step 8: Updates and rollback

The simplest update is git pull && npm ci && npm run build && pm2 reload api. The danger: if the build fails halfway, your running code and your files no longer match. A safer layout is releases/<timestamp> folders plus a current symlink that you switch only after a successful build.

The same deploy with ShipOwn

Steps 3 to 8 are the repetitive part. ShipOwn is a desktop app for Windows, macOS and Linux that does them over SSH from your machine. No ShipOwn agent is installed on your Hetzner server.

Connect a server: paste the Hetzner IP, user deploy, and your key. The connection is tested before it's saved.
Pick a source: your GitHub repo and branch, or a local folder.
Review the plan: ShipOwn detects the framework (Express, NestJS, Fastify and others) and proposes install, build and start commands, port and domain. Edit anything, then approve.
Watch it build: logs stream live from the server, or build on your PC and upload the output.
Operate it: live URL, deployed commit, health, logs, redeploy, rollback.

What it handles for you:

PM2 process with port, health check and restart policy.
Nginx virtual host, tested before reload, and restored if Nginx rejects it.
Certbot certificate when you want HTTPS, with expiry shown in the app.
A release directory per deploy, so a failed deploy restores the previous release and you can roll back later.
fail2ban can be installed and viewed from the app.

You also get a server view with CPU, RAM, disk, load and PM2 processes, read straight from the server, plus an embedded terminal. Nothing extra is installed to collect these metrics.

Troubleshooting on Hetzner

Can't connect on port 80/443: check the Hetzner Cloud Firewall as well as ufw on the server. Both must allow the port.
502 from Nginx: the app isn't listening on the port Nginx expects. Check pm2 logs.
EADDRINUSE: another process already uses the port. sudo ss -ltnp | grep 3000.
413 Request Entity Too Large: raise client_max_body_size.

If you're stuck, ShipOwn's AI terminal (using your own Anthropic, OpenAI or DeepSeek key) proposes one command at a time with a reason, and you approve each one.

FAQ

Does ShipOwn work with Hetzner dedicated servers too? It targets any Linux server you can reach over SSH: a VPS, a cloud VM or bare metal.

Do I need Docker? No. Node apps run under PM2. Docker apps are supported if you prefer containers.

Conclusion

Hetzner gives you a clean, fast Linux box. Do the setup once by hand so you understand it, then use ShipOwn for repeat deploys, HTTPS and rollback. It has a free 30-day trial, no card required.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

7 Heroku Alternatives for Self-Hosting Your App in 2026 (Own the Server)

Vishvajeet Shukla — Wed, 28 Oct 2026 07:30:57 +0000

Heroku made deployment feel like magic: git push, wait a minute, get a URL. For a lot of developers that magic is still the benchmark. But more teams now want the same workflow on a server they rent and control, instead of on someone else's platform and bill.

This guide looks at seven realistic Heroku alternatives for self-hosting in 2026. All of them put your app on a Linux server you own. They differ in how much they install on that server, how much you do by hand, and how you recover when something breaks.

Quick answer

Want full control and don't mind commands? Manual SSH + PM2 + Nginx + Certbot.
Want a web dashboard living on the server? Coolify, Dokploy or CapRover.
Want a Heroku-like flow from your desktop, with nothing installed on the server? ShipOwn.
Want a single-purpose deploy script? A shell script or a CI job that SSHes in.

What "Heroku alternative" really means

Heroku gave you four things:

A build step that knows your framework.
A process manager that keeps the app running and restarts it.
Routing and HTTPS to a domain.
Releases and rollback so a bad deploy is one click to undo.

Any self-hosted replacement has to cover the same four jobs. On a VPS those jobs are usually done by Node or Docker (build), PM2 or containers (process), Nginx and Certbot (routing and HTTPS), and some release-directory scheme (rollback). The question is who wires them together: you, a dashboard on the server, or a tool on your machine.

1. Manual SSH, PM2, Nginx and Certbot

This is the baseline every other option automates.

ssh deploy@your-server
git clone https://github.com/you/app.git && cd app
npm ci && npm run build
pm2 start npm --name app -- start
sudo nano /etc/nginx/sites-available/app   # proxy_pass http://127.0.0.1:3000;
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

Good: nothing extra on the server, you learn exactly how it works.
Bad: every deploy repeats these steps, rollback is something you have to invent, and one bad Nginx edit can take down other sites on the same box.

2. Coolify

Coolify is an open-source self-hosted platform. You install it on your server and use its web dashboard to deploy apps, which run as Docker containers.

Good: a Heroku-style dashboard, many one-click services.
Trade-off: the platform itself runs on your server and uses resources there, and your apps go through Docker.

3. Dokploy

Dokploy is another open-source platform you install on the server. It is also Docker-based and gives you a web UI for applications and databases.

Good: modern UI, Docker and Compose focused.
Trade-off: same model as Coolify, a control plane next to your apps.

4. CapRover

CapRover has been around for years. It installs on your server, uses Docker (Swarm under the hood) and gives you a dashboard plus a CLI.

Good: mature, simple captain-definition files.
Trade-off: Docker is required, and the platform lives on the server.

5. ShipOwn (desktop app, no server agent)

ShipOwn takes a different approach. It is a desktop app for Windows, macOS and Linux that connects to your Linux server over plain SSH. No ShipOwn deployment agent is installed on the server; it uses the tools that are already there or that it sets up for you.

The flow mirrors Heroku's:

Connect a server: host, port, user, key or password. The connection is tested before it is saved.
Pick a source: a GitHub repo and branch, or a folder on your computer.
Review the plan: framework, install/build/start commands, port, domain and target are detected and every value is editable.
Watch it build: on the server or on your PC, with output streaming live.
Operate it: live URL, history, health, logs, redeploy and rollback.

What it deploys:

Node apps under PM2: Next.js, Nuxt, Remix, SvelteKit, NestJS, Fastify and plain Express.
Static sites on Nginx: Vite (React or Vue), Astro or plain HTML.
Docker apps: a Dockerfile or a Compose file. This also covers Python, Go, PHP and other languages, as long as they ship in a container.

Docker is optional. A Node app can run under PM2 on a server with no Docker at all.

Good: no control plane on the server, release directories with rollback, Nginx config tested before reload, an AI terminal that proposes one command at a time for your approval.
Trade-off: no auto-deploy on push (it tells you how many commits a branch is ahead, but a person presses deploy), and it is a commercial app, not open source.

6. A deploy script or CI job

A GitHub Actions workflow that SSHes in, pulls, builds and restarts PM2 is a perfectly valid Heroku replacement for one app.

Good: auto-deploy on push, free for small usage.
Bad: you still write and maintain the Nginx, HTTPS and rollback parts yourself.

7. A managed VPS panel

Classic control panels can host Node apps too, but they are usually aimed at PHP hosting and email. They fit if you already run one; they are rarely the simplest path for a modern JavaScript app.

Comparison table

Option	Installs on server	Docker required	Rollback	Dashboard location
Manual SSH	Nothing extra	No	DIY	Your terminal
Coolify	Platform	Yes	Yes	Web, on server
Dokploy	Platform	Yes	Yes	Web, on server
CapRover	Platform	Yes	Yes	Web, on server
ShipOwn	No deployment agent	No (optional)	Yes, retained releases	Desktop app
CI script	Nothing extra	No	DIY	GitHub

How to choose

Ask three questions:

Do you want anything running on the server besides your app? If not, look at manual SSH, a CI script or ShipOwn.
Are your apps already containerised? If yes, Coolify, Dokploy and CapRover are natural fits. If they are plain Node apps, PM2 is lighter.
Who fixes it at 2 a.m.? If it's you, pick the option where rollback and logs are one click away.

Migrating a Heroku app to a VPS: checklist

Copy every config var from Heroku into a .env (or the tool's env editor). Remember that PORT is now yours to choose.
Replace Heroku Postgres/Redis add-ons with a managed database or a container on the server, and plan backups.
Point your domain's A record to the server IP.
Issue HTTPS with Certbot (or let your tool do it).
Keep the Heroku app running until the new URL passes a health check, then switch DNS.

FAQ

Is self-hosting cheaper than Heroku? Often, because one VPS can run several small apps, but you take on maintenance. Measure with your own numbers.

Can I get git push deploys with ShipOwn? Not today. ShipOwn shows that a branch has new commits, and you deploy with one click.

Do I need Docker to leave Heroku? No. Node apps run fine under PM2 behind Nginx.

Conclusion

Leaving Heroku doesn't mean going back to hand-written configs. If you like a server-side dashboard, Coolify, Dokploy and CapRover are solid. If you want the Heroku-style flow from your desktop and a clean server, try ShipOwn. It starts with a free 30-day trial, and no card is needed.

Written by Vishvajeet Shukla, full stack developer and creator of ShipOwn.

Vercel vs Firebase for Next.js Hosting: Which Is Best in 2026?

Vishvajeet Shukla — Wed, 28 Oct 2026 06:28:23 +0000

Where you host a Next.js app is more than a DevOps detail: it affects speed, cost, and how much backend you have to build yourself. Two common options are Vercel (built around the Next.js workflow) and Firebase (Google’s app platform with hosting plus many backend services).

This guide compares them for 2026 projects: marketing sites, dashboards, and products that need auth and data. I am Vishvajeet Shukla, a full-stack developer who ships Next.js sites for Indian and international clients. Related: hire a Next.js developer · Core Web Vitals guide · website cost guide.

Quick verdict

Pick Vercel when Next.js features (SSR/SSG/ISR, App Router, previews) are the product surface and you want the least friction deploying frontends.
Pick Firebase when you want hosting plus a ready ecosystem (Auth, Firestore, Storage, Functions) under one Google cloud umbrella — and you accept more assembly for advanced Next.js rendering modes depending on setup.
Hybrid is normal: Next.js on Vercel + Firebase Auth/Firestore, or Firebase for mobile + Next marketing site on Vercel.

Comparison table

Factor	Vercel	Firebase
Best known for	Next.js frontend platform	Backend + hosting suite
SSR / App Router DX	Excellent, first-class	Possible; more config tradeoffs
Preview deployments	Outstanding PR previews	Available; different workflow
Auth / DB included	Bring your own	Auth, Firestore, RTDB, Storage
Serverless functions	Edge / serverless functions	Cloud Functions
Typical sweet spot	Sites, marketing, SaaS UI	Apps needing BaaS quickly
Pricing shape	Bandwidth/build/team tiers	Usage of many products

What Vercel optimises for

Vercel’s mental model is: git push → production, with previews for every PR. Image optimisation patterns, caching, and framework defaults align tightly with Next.js. For SEO-focused business sites, that usually means faster iteration and fewer “why is my SSR broken?” moments.

You still need a database and auth strategy (Postgres, MongoDB, Supabase, Firebase, etc.). Vercel is not a full backend replacement.

What Firebase optimises for

Firebase optimises for shipping product features quickly: sign-in, realtime data, file uploads, push notifications, analytics. Hosting is one piece of a larger kit. Teams that want one vendor for many app services often land here.

For content-heavy marketing Next.js sites, you must still design rendering, SEO metadata, and caching carefully — Firebase Hosting alone does not magically make a slow app fast.

Next.js rendering modes and why hosting choice matters

Static / SSG pages: both can serve well with a CDN
SSR / dynamic routes: platform support and cold starts matter
ISR / revalidation: developer experience differs by host
Edge logic: useful for geo or auth gates; check product limits

If your site is mostly static brochure pages, almost any solid host works. If you lean on App Router server components and dynamic data, prefer the platform that documents your exact path clearly.

Pricing mindset (not a quote sheet)

Both can be cheap at low traffic and expensive when misconfigured. Watch:

Bandwidth and image transformation costs
Function invocation volume
Realtime database read/write patterns (Firebase)
Team seats and commercial plan features
Egress if you mix multiple clouds poorly

Always model your expected monthly active users and peak campaign traffic before locking architecture.

Security and operations

Environment secrets management
Role-based access to production projects
Preview environments that never touch live customer data carelessly
Backup strategy for databases
Monitoring for 5xx and function errors

Ownership matters: your client should control the billing account and project, not a personal freelancers login that vanishes later.

Decision checklist

Is this mostly a marketing site or a data app?
Do we need Firebase Auth/Firestore specifically?
How important are PR preview deployments?
Who will maintain the stack in 12 months?
What is the budget ceiling for traffic spikes?

Recommended pairings I often use

Business marketing site: Next.js on Vercel + forms to email/CRM + WhatsApp CTAs
MVP app: Next.js UI + Firebase Auth/Firestore (or Supabase) depending on SQL needs
Content + product: Next.js marketing on Vercel, app subdomain on chosen BaaS

See also backend tradeoffs in Supabase vs Firebase when that post is relevant to your stack.

Common mistakes

Choosing Firebase only because “Google” without a data model plan
Choosing Vercel then inventing a fragile homemade auth in a rush
Ignoring cold starts on rarely hit serverless routes
No staging environment
Leaving projects on a personal free account forever

FAQ

Can I host Next.js only on Firebase?

You can host many Next.js outputs, but advanced rendering workflows are often smoother on Vercel. Validate your exact Next version and features against current Firebase docs before committing.

Is Vercel only for small sites?

No. Teams run large production frontends there. Cost governance and architecture still matter at scale.

What about India latency?

Both use global CDNs. Measure TTFB for your audience cities; choose regions/config accordingly.

Team skills and hiring impact

Your hosting choice should match who will maintain the system. A marketing team that only needs content updates benefits from a boring, well-documented Next.js deploy pipeline. A product team shipping mobile + web features may prefer Firebase’s client SDKs even if the marketing site lives elsewhere.

When freelancers hand over a project, insist on: repository access, environment variable list, domain DNS notes, and which Google/Vercel project owns production. Orphaned personal accounts are a common disaster six months later.

SEO implications of hosting

Hosting does not replace content strategy. It does affect TTFB, uptime, HTTPS, redirects, and how easily you ship metadata fixes. Prefer platforms where preview deployments let you QA SEO changes before production. After go-live, connect Search Console and monitor coverage — not only homepage rankings.

Practical architecture recipes

Local service business site: Next.js on Vercel, form to email, WhatsApp CTAs, optional CMS.
Catalogue exporter: Next.js frontend, image CDN, enquiry to CRM; Firebase optional for auth if dealers log in.
Chatty MVP app: Firebase Auth + Firestore, Next.js UI, careful security rules review.
SQL-heavy SaaS: Postgres (Supabase or managed SQL) + Next.js; Firebase usually not the core DB.

Migration notes if you switch later

Moving hosts is easier when content lives in git or a CMS, not only in a closed page builder. Keep URLs stable. Export analytics annotations on migration day so you can explain traffic dips. Never change DNS and rendering mode in the same hour without a rollback plan.

Next step

Write your must-have features (auth, CMS, payments, SSR pages). Map each to a service. Then pick the host that makes the frontend path boringly reliable.

Need a production Next.js setup? Contact · Projects · vishvajeet4711@gmail.com · more on the blog.

Originally published at vishvajeetshukla.in. Need a developer? Hire me.

Node vs Python vs Go for AI Backends (2026)

Vishvajeet Shukla — Wed, 28 Oct 2026 06:27:54 +0000

An AI feature is roughly half model prompts and half boring backend work: auth, rate limits, queues, webhooks, and cost control. That is why the stack question — Node/Express, Python, or Go for an AI backend in 2026 — comes up on day one.

Short answer up front: Python for heavy AI/RAG experimentation, Node when your product is already JavaScript/TypeScript, Go when you need ultra-efficient service glue at scale — not as your first LangChain tutorial language.

I am Vishvajeet Shukla, a full-stack developer working across Next.js, Node, and AI integrations. Related: LangChain RAG website agent · developer blog.

Decision table (2026 practical view)

Need	Best default	Why
LangChain / notebooks / research pace	Python	Ecosystem depth
Next.js site chatbot on same repo	Node / TS	One language, simple deploy
High QPS gateway, low memory	Go	Efficient concurrency
Fast MVP for client demo	Node or Python	Whichever your team ships faster
ML training pipelines	Python	Not even a contest

Node.js + Express (or Next.js route handlers)

Strengths

Same language as React/Next frontends
Great for streaming responses to the browser
LangChain.js, Vercel AI SDK, OpenAI official SDKs are solid
Easy JSON APIs, middleware, auth patterns for web apps

Watch-outs

CPU-heavy embedding of huge corpora can block the event loop if you do it naively
Move bulk ingest to workers/queues

Use Node when: your portfolio or SaaS is already TS, and the agent is a product feature not a research lab.

Python (FastAPI / Django Ninja / Flask)

Strengths

LangChain, LlamaIndex, eval tools, notebooks everywhere
Fastest path to try retrieval strategies
Data cleaning and PDF parsing ecosystem

Watch-outs

Extra service to deploy if the main app is Node
You must still design production concerns (timeouts, workers, observability)

Use Python when: RAG quality and iteration speed matter more than monorepo purity.

Go

Strengths

Simple concurrency model, small binaries, predictable performance
Excellent for API gateways, rate limiters, fan-out proxies

Watch-outs

AI orchestration libraries and examples lag Python/JS
You will call model HTTP APIs yourself more often

Use Go when: you already know Go and need a thin, fast control plane — not when learning RAG for the first time.

LangChain workflow: which language?

Learning RAG + agents quickly → Python
Shipping on a Next.js portfolio with existing API routes → Node/TS (LangChain.js)
Hardening a multi-tenant gateway later → maybe Go in front of either

Full agent pattern: LangChain RAG for website AI agents.

Architecture patterns that beat language debates

Sync API for short chat turns
Queue + worker for re-indexing site content
Stream tokens to UI for perceived speed
Cache frequent answers
Separate secrets from the frontend bundle

Language does not fix a missing rate limiter.

Performance and cost realities

Model tokens dominate cost more than language runtime for most MVPs
Retrieval quality dominates answer quality more than framework brand
Cold starts matter on serverless — warm workers help long RAG chains

Team and hiring angle (India freelancing reality)

More full-stack freelancers are comfortable in JS/TS
AI/ML specialists lean Python
Go talent is excellent but smaller pool for AI-feature MVPs

Ship with the language your maintainer can debug at 11pm.

Recommended defaults by project type

Project	Backend pick
Portfolio chat over blogs	Node (Next API) + vector DB
Document-heavy enterprise RAG	Python worker + any web API
WhatsApp AI session service	Node or Python + Redis
Multi-tenant AI gateway at scale	Go edge + Python/Node workers

Express server sketch (when Node is right)

// conceptual only
app.post('/api/chat', rateLimit, auth, async (req, res) => {
  const chunks = await retrieve(req.body.question)
  const answer = await generate({ question, chunks })
  res.json({ answer, sources: chunks.map(c => c.url) })
})

Add streaming, timeouts, and abuse controls before public launch.

Python FastAPI sketch (when Python is right)

# conceptual only
@app.post("/chat")
async def chat(q: Query):
    chunks = await retrieve(q.text)
    answer = await generate(q.text, chunks)
    return {"answer": answer, "sources": [c.url for c in chunks]}

My personal recommendation for most website agents

If the product is a Next.js site (like many modern portfolios and SaaS marketing apps): start with TypeScript + LangChain.js or Vercel AI SDK. Spin a Python service only when ingest/eval complexity outgrows the JS tooling.

Reach for Go when traffic and infrastructure concerns dominate, not when you are still writing the first system prompt.

SEO/AdSense note for developer blogs

Comparison posts like this earn developer traffic when they stay practical and updated. Keep examples honest, avoid fake benchmarks, and link to deeper tutorials. That is also the AdSense-safe way: real teaching, not scraped listicles.

FAQ

Is Express outdated for AI APIs?

No. Express (or Fastify) is still fine. Next.js route handlers are also fine. Structure and ops matter more than the framework logo.

Is Python slower than Go for chat APIs?

For typical LLM calls, network and model latency dominate. Language microbenchmarks rarely decide UX.

Can I mix all three?

Yes — many mature systems do. Start with one to reduce ops pain.

What about Rust?

Great for specialised high-performance components. Overkill for most first AI agents.

What should freelancers learn first?

If you sell web apps: TypeScript + one RAG path. Add Python when clients need heavier data workflows.

Next step

Tell me your current stack (Next.js, Express, Python, etc.) and whether the agent must live inside the same repo. I will recommend a concrete backend layout.

Contact form · vishvajeet4711@gmail.com · Projects

Originally published at vishvajeetshukla.in. Need a developer? Hire me.