Staging and Git deploy
€690from proposed
- Protected staging copy with safe email and payments
- Git-based deploy to cPanel or a VPS
- Release folders and one-command rollback
- Written runbook and one walk-through call
Ship changes safely: staging, deploys and rollbacks that just work
Git-based deployment to cPanel or your VPS, a staging copy of the site, automated checks and one-command rollbacks, so updates stop being scary. For agencies and teams on PHP projects. From €690.
from€690excl. VAT 25.5%. Fixed price, written quote within one working day.
pipeline: example-site, branch mainsample pipeline, example timings
Project
Server
Commit01
Not starteda1b2c3d "Fix VAT label on checkout"Checks02
Not startedThree checks for Laravel:- Lint queued
- Tests queued
- Static analysis queued
Staging03
Not startedstaging.example.fi, password protectedApprove04
Not startedA person, not a script, says goProduction05
Not startedexample.fi, now on r41
Break a check on purpose:
sample server: web1.example.fi (203.0.113.20) and CI runnerlatest 12 lines# ready: push the sample change# production is on r41
releases on web1.example.fi
/var/www/example/current -> releases/r41
- r41Core and plugin updates, 8 Octcurrent
- r40New contact form, 6 Oct
- r39Update shipping rates, 2 Oct
Old releases stay on disk, so rolling back is one symlink switch, not a restore.
Ready. Push the sample change, or break a check first to watch the pipeline stop.
Push the sample change, approve it, then roll it back. Break a check first to watch the pipeline stop before anything reaches a server.
Local, staging and production: what differs and where secrets live
Three copies of the same site with deliberately different settings. Code flows up, data flows down, and secrets stay out of Git. Pick a topic to follow it across all three.
| topic | Locala developer laptop | Stagingstaging.example.fi | Productionexample.fi |
|---|---|---|---|
| Code | Any branch, on the laptop | The branch under review, deployed by CI | Only approved releases, one folder each |
| Data | A small anonymised subset | A copy of production with personal data masked | The real data, backed up nightly off-site |
| Caught by a local mail catcher such as Mailpit | Sent to one catch-all inbox, never to customers | Real sending with SPF, DKIM and DMARC | |
| Payments | Provider test mode keys | Provider test mode keys | Live keys, only on the production server |
| Search engines | Not reachable from outside | Password protected and noindex | Indexable, with a real robots.txt |
| Errors | Full error output on screen | Logged, and shown to testers | Logged, never shown to visitors; alerts on spikes |
| Secrets | .env file, listed in .gitignore | Encrypted CI secrets, written to .env on deploy | .env readable only by the deploy user (chmod 600) |
Secrets: Secrets never enter Git. CI holds them as encrypted environment secrets and writes them on deploy, so rotating a key means changing one place.
What I set up
Plain tools that your team, or the next developer, can understand without me: Git, a CI service, SSH and a few shell scripts.
Git as the source of truth
One repository, main for production, branches for work. Nobody edits files on the live server over FTP again.
Checks on every push
Lint, tests, static analysis or coding standards, and a dependency audit, run in GitHub Actions or your CI of choice.
A staging copy
Password protected and noindex, with real email and live payments switched off, refreshed from production on request.
Atomic releases
Each deploy lands in its own folder; a symlink switch makes it live at once, so visitors never see half-copied files.
One-command rollback
The previous releases stay on disk. Going back is one symlink and a PHP reload, written down in the runbook.
Safe database changes
Migrations written expand first, contract later, so the previous release still runs if you roll back.
Secrets out of Git
.env files on servers, encrypted CI secrets, deploy keys with the narrowest access that works.
For agencies
The same pipeline across client projects, white-label if you prefer. See working with agencies.
Afraid to press update on a Friday? Send the repo and hosting details for a fixed quote.
Get a deployment quoteHow the set-up runs
Your live site keeps working the old way until the first pipeline deploy has gone through with you watching.
- 1
Look
Read access to the repository and SSH or cPanel access to the server, created by you, removable by you.
- 2
Staging
A protected copy of the site with email and payments made safe, matching production's PHP version.
- 3
Pipeline
Checks, staging deploys, an approval step and release folders, built in a branch and tested on staging.
- 4
First deploy
A real change shipped together, then a deliberate rollback, so you have seen both work once.
- 5
Handover
A short runbook. You own the repository, the CI account and every secret.
Deployment packages
Fixed prices in euros, excluding VAT 25.5%, per project. You own the repository, the pipeline and every account.
Full pipeline
€1,190from owner to confirm
- Everything in Staging and Git deploy
- CI checks: lint, tests, static analysis, audit
- Approval step before production
- Encrypted CI secrets and deploy notifications
Agency rollout
Quoteper batch of projects owner to confirm
- One pipeline template for your stack
- Applied to several client projects
- White-label documentation if needed
- Optional ongoing care per server
If the pipeline cannot deploy your project cleanly by handover, I keep working on it at no extra cost until it does. owner to confirm Ongoing server care is a separate managed care plan.
Questions about deployment automation
Can this run on shared cPanel hosting?
Usually, yes. cPanel's Git Version Control can deploy a repository through a .cpanel.yml file, and many hosts allow SSH, which is enough for release folders and a symlink switch. What shared hosting rarely allows is long-running workers or custom services, so builds and checks run in CI instead of on the server.
Do you set up GitHub Actions?
Yes, it is my default. A workflow runs lint, tests and analysis on every push, deploys to staging, waits for a required reviewer, then releases to production. Secrets live in GitHub environment secrets, not in the repository. GitLab CI and Bitbucket Pipelines work the same way if your team already uses them.
Can you add staging to an existing site?
Yes, that is the most common starting point. I copy the live site to a staging subdomain, protect it with a password and noindex, stop it sending real email or taking real payments, then add a simple way to refresh it from production. Git and automated deploys can follow later, step by step.
When I would not recommend this
A pipeline is worth it when changes are frequent or risky. Otherwise it is ceremony.
- 01A small brochure site edited a few times a year. A backup before each edit and a care plan cost less.
- 02Site builders such as Wix or Squarespace, with no file or SSH access. There is nothing to deploy to.
- 03The team will not use Git. A pipeline nobody pushes to is clutter; start with Git habits, then add the pipeline.
Get a deployment quote
Send the site address, where it is hosted and how you deploy today, even if the answer is FTP. You get a written fixed price within one working day.
Prefer email? Write to hei@pikselipolku.fi
Pikselipolku is an independent studio and is not affiliated with cPanel, LiteSpeed or any other product named here.