CI/CD pipeline on a VPS: deploy without downtime

Your app runs on a VPS, and for a while the deploy ritual is fine: SSH in, pull, restart, refresh, hope. Then one Friday it isn't fine anymore. A CI/CD pipeline on a VPS collapses that ritual into a single path — same checks, same build, same publish, whether it is 10 a.m. on a Tuesday or 1 a.m. before a launch. What follows is a tool-agnostic reference setup, the failure modes worth designing around, and what each placement option actually costs.

What you take ownership of when the pipeline lives on your box

Managed platforms bundle continuous integration as a service: you push, something builds. On a VPS you inherit the machinery. That is the point — the pipeline becomes predictable and yours to audit — but it is worth being explicit about what stops being someone else's problem.

• The runner. Builds consume CPU and memory in bursts. That load profile has nothing to do with visitor traffic, and sizing for one does not size for the other.
• The secrets. Deploy keys, API tokens, database passwords: creation, storage, rotation and revocation are now your procedure.
• The disk. Artifacts, container layers and old releases pile up quietly until a build dies on a full partition.
• The rollback. Nobody upstream will restore your previous version. If the command does not exist before the first incident, you will improvise during it.
• The audit trail. Build logs, deploy history and the version currently in production all sit on the machine, waiting to be kept and backed up.

A four-stage reference architecture

Keep the stages separate and each one becomes replaceable without touching the others.

1. Repository and trigger

Git stays the source of truth. The trigger is an event: a push to the main branch, a version tag, an approved merge request. Resist building on every branch — a pipeline that runs constantly burns CPU and buries real failures in noise.

2. Runner: where the work happens

The runner receives a job and executes it. The structural decision is placement: on the application VPS, or on its own machine. Co-locating is cheaper and fine for a small team. Separating keeps compiles away from user traffic, which starts to matter the first time a build eats the memory your app needed.

3. Build: emit an artifact, not a checkout

A healthy build never lets a working copy land in production. It produces an artifact — a tarball, a release directory, a container image — tagged with the commit or the version. Production receives that artifact and never runs a blind git pull. You then know exactly what is live, and you can rebuild it identically.

4. Deploy: SSH plus an idempotent script

Deployment runs over SSH with a dedicated key and a script that converges on the same state however often you run it. Stop, copy, activate, verify, then decide: keep or revert. No manual copy-paste, and no surprises the second time.

Zero downtime with atomic releases

The technique is old and still the best default: never overwrite the app in place. Each deploy gets its own dated directory, and a symlink flips the switch.

1. Build the artifact and place it in /srv/app/releases/2026-11-07-1.
2. Install dependencies and run migrations inside that directory, offline.
3. Point the current symlink at the new release — one atomic operation.
4. Reload the app service (PHP-FPM, a systemd unit, a container) without stopping the web server.
5. Call a health endpoint and check both the status code and the version it reports.
6. On failure, flip the symlink back to the previous release and reload again.
7. Keep the last three to five releases, then delete the rest.

This covers the large majority of deploys. It does not make a destructive migration safe: dropping a column is still dropping a column. Split those changes into three steps — add the new column, deploy code that writes to both, then remove the old one in a later release.

Secrets, accounts, permissions

A pipeline holds production keys, so treat it as privileged access rather than a convenience script.

• A dedicated deploy account, with no interactive shell where possible, and never root.
• One SSH key per pipeline, stored encrypted or passphrase-protected, revocable with a single command.
• No secrets in Git — not even in a commit you deleted, because history is readable.
• An environment file readable only by the deploy account, for example /etc/app/env at mode 600.
• An isolated runner if your builds execute code from outside contributors.
• A rotation calendar for tokens, and immediate revocation when someone leaves.

One detail that bites teams late: build logs. Masked variables are easy to misconfigure, and a token printed once in a log is a token leaked. Read one full log before opening log access to the whole team.

How many VPS does a pipeline need?

Here are the realistic placements, with Open Vista's five NVMe VPS plans at their published prices. Every plan includes a dedicated IPv4, unlimited bandwidth, automatic backups, DDoS protection, 24/7 supervision, support six days a week and delivery in under 15 minutes after ordering.

The arithmetic is not about core count. A three-minute build peaking at half a gigabyte does not need the same machine as a full asset compile. Start small, measure peak memory during builds, then resize — moving to a larger plan does not require a painful migration. Full specifications are on the VPS plans page, and dirham prices follow the site convention of 1 USD ≈ 9.46 MAD on the pricing page.

Rollback, monitoring, backups

A deploy is not finished when the script exits. Three signals decide whether the release stays: the health endpoint's status code, the error rate in application logs over the next ten minutes, and median response time. If any of the three degrades, rollback should be a command, not a meeting. Keep the release-to-commit mapping too — the day an incident traces back to a specific version, you save hours.

On the infrastructure side, the VPS plans include automatic backups and 24/7 supervision, with a 99.9% SLA on infrastructure. That SLA covers the machine being up, not your code being correct — a distinction worth stating plainly to your team and to your clients.

FAQ

Do I need a separate server for the runner?

Not at the start. On a 2 to 4 GB VPS a runner coexists with the app while builds stay short and memory is controlled. Move it off as soon as a compile causes visible slowdowns or out-of-memory errors on the production host.

Can a plain SSH script really deploy with no downtime?

Yes, with atomic releases and a symlink flip: the switch is instantaneous and the app reload takes seconds. Downtime usually comes from database migrations or from a service restarted without a queue, rarely from the switch itself.

Where should pipeline secrets live?

In your CI tool's secret store if it has one; otherwise in a restricted environment file on the server, outside Git. Either way, a dedicated deploy account and a revocable key remain the baseline.

How do I return to the previous version?

Flip the symlink to the previous release and reload the service. That is exactly why you keep several releases on disk: without them, rollback becomes manual work under pressure.

Next step: a predictable VPS for your deploys

A useful pipeline needs no exotic platform and no large budget: a repository, a runner, an idempotent deploy script and a rollback procedure. The rest is discipline, and discipline is cheaper than incidents. Open Vista's NVMe VPS plans are delivered in under 15 minutes with root access, a dedicated IPv4, automatic backups and 24/7 supervision — enough to run CI and production on one machine, or on two if you prefer to keep builds away from traffic.

Compare the five configurations on the VPS plans page, then check the dirham pricing on the pricing page. Still unsure whether to split the runner? Tell us your stack: the decision hinges on peak memory, not on the vCPU number printed on the plan.