Direct-to-prod

The model

You keep the repo on the VPS (~/hackup). You push to GitHub from the box, or pull from it. When you want to ship, you run one script that builds and restarts. There is no CI pipeline to wait on, no container to build, no orchestrator. The box is the environment.

This is how this site ships. It is fast, it is boring, and it is easy to reason about.

1. systemd services

Create a unit for your app. Example /etc/systemd/system/hackup-web.service:

[Unit]
Description=HackUp web (Astro SSR)
After=network.target

[Service]
User=hackup
WorkingDirectory=/home/hackup/hackup
EnvironmentFile=/home/hackup/hackup/.env.production
ExecStart=/usr/bin/node /home/hackup/hackup/dist/server/entry.mjs
Restart=on-failure
RestartSec=2

[Install]
WantedBy=multi-user.target

Then:

sudo systemctl daemon-reload
sudo systemctl enable --now hackup-web

systemd now keeps your app up, restarts it on crash, and starts it on boot.

2. The deploy script

In package.json:

"scripts": {
  "build": "astro build",
  "build:api": "esbuild ...",
  "deploy:vps": "npm run build:all && sudo systemctl restart hackup-web hackup-api"
}

Shipping becomes:

cd ~/hackup
git pull
npm run deploy:vps
sudo journalctl -u hackup-web -n 20   # check it started clean
curl -s http://127.0.0.1:8793/ | head   # smoke test

3. Rollback

Because the box is the environment and git is the source of truth, rollback is trivial:

git log --oneline -5          # find the last good commit
git checkout <prev>
npm run build && sudo systemctl restart hackup-web

You are back to the previous version in under a minute. No pipeline to reverse, no images to re-tag.

4. When to use this

Solo or small team: direct-to-prod is fine for almost everything.
Add a staging box or a CI pipeline only when you have humans reviewing PRs you can’t eyeball yourself.
Always commit before you let the agent ship, so git checkout . is your undo.