Can I deploy to my own VPS from GitHub Actions?

Yes, and it is simpler than most platform-specific deploy setups. The workflow checks out your code, then connects to your server over SSH using a deploy key stored in GitHub secrets, and runs your deploy commands there - pull the new code, build if needed, and restart the service. No platform lock-in: it is just SSH to a box you control, so the same workflow works on any VPS, bare-metal host, or cloud.

How do I store the SSH key safely?

Generate a dedicated deploy key pair, put the public key in the server user's authorized_keys, and store the private key as a GitHub Actions secret (the workflow reads it from secrets, never from the repo). Use a key used only for deploys, scope the server user's permissions to what the deploy needs, and you can revoke it any time by removing the public key from the server.

systemd, docker compose, or a registry - which mode?

Use systemd if you run the app directly on the host as a service - the deploy pulls code and restarts the unit. Use docker compose if your app and its dependencies run as containers from a compose file on the server. Use the registry mode if you want CI to build the image and push it to a registry (like GHCR), and the server just pulls the built image - cleaner for bigger apps and faster restarts.

Free tool · Runs in your browser

Deploy to a server you own.

Push to main, and your app ships to your own box — no platform, no lock-in, just SSH to infrastructure you control. Pick how you run it and get a GitHub Actions workflow, the secrets to set, and the one-time deploy-key setup.

How your app runs on the server

Deploy path on server

systemd service name

Branch to deploy

Build step (optional, server-side)

.github/workflows/deploy.yml

Secrets to add

First-time setup

Your repo, your server, no middle layer

Platform deploys are convenient until the platform's pricing, limits, or outages become your problem. Deploying straight from GitHub Actions to a box you own keeps the convenience — push to a branch, it ships — without handing the keys to anyone. It's just SSH and a few commands, which means it works the same on any host and moves with you if you ever change providers.

The workflow is the easy 90%. The other 10% — making sure the deploy actually succeeded, that a bad release can roll back, that you have a record of what shipped and who triggered it, and that the service comes back if it crashes after deploy — is the operational layer a platform used to hide. That's the part a control plane gives back to you, on your own infrastructure.

Related free tools

systemd service generatorKeep your app running Reverse proxy + HTTPSCaddy / nginx + HTTPS Backup script generatorDump, offsite, restore RPO / RTO calculatorData loss + downtime

All free tools →

Ship it. Then know it shipped.

Infraveil gates every deploy behind your approval, verifies it landed, rolls back a bad one, and keeps a tamper-evident record of what shipped — turning a push-to-deploy workflow into a deploy you can trust, on servers you own.

See how it works

Get the self-hosted deploy playbook

CI/CD, rollbacks, and safe deploys to infrastructure you own. No spam.