01
Deploying via FTP
Files dragged into FileZilla. No history, no rollback. One wrong overwrite and the site breaks, and you hear about it from a customer.
FTP uploadgit push
Stop deploying via FTP
Jaipur, India · Laravel, CI4, WordPress, Node.js
DevOps & CI/CD:
Push to main.
Tests run.
Production updates.
DevOps and CI/CD setup from our Jaipur team: GitHub Actions pipelines, staging environments, Docker, server hardening and zero-downtime releases for Laravel, CodeIgniter 4, WordPress and Node.js apps. Every deploy tested, logged and reversible.
- Fixed price, scoped before we start
- Staging before production
- Documented handover
DevOps set up by the developers who build the apps.
We write Laravel, CodeIgniter, WordPress and Node.js code every day, so the pipeline runs the commands your app really needs: migrations, cache clears and PHP-FPM reloads included.
60s
Typical deploy
1click
Production approval
1cmd
Rollback
What we fix
Six signs your deployment workflow is a liability.
Every manual step in a deployment is a risk. Most platforms we inherit have at least four of these, and each one is fixed by a pipeline.
02
No test environment
Every plugin update, code fix and config change goes straight to production. Testing means hoping, and breaking means downtime.
Live onlyStaging first
03
Live code not in version control
The code on the server does not match the repo, or there is no repo. Nobody can tell what changed, when, or who changed it.
Unknown changesFull Git log
04
Manual deploys take 30+ minutes
SSH in, git pull, composer install, run migrations, clear cache, restart PHP. Every time, by hand, while somebody holds their breath.
30 min by handAutomatic
05
No rollback plan
A bad deploy goes live and the only option is to reverse the changes by memory. You end up debugging in production under pressure.
Undo by memoryOne revert
06
Only one person can deploy
Deployment is tribal knowledge. If that person is on leave or has left, nobody can safely push a change.
One personWhole team
Before and after
What a CI/CD pipeline changes.
Continuous integration runs your checks on every push. Continuous delivery ships the code that passed them, the same way every time. The result is fewer surprises and a deploy anyone on the team can do.
See the setup plansWithout CI/CD
With our pipeline
FTP upload, about 25 minutes
Git push, live in about 60 seconds
Migrations run by hand on production
Migrations run automatically
Nothing tested before deploy
Tests run before every deploy
No record of what changed
Full audit log in GitHub
Rollback: undo files manually
Rollback: one git revert and push
Needs one specific person
Anyone with repo access can deploy
Site down during the deploy
Zero-downtime release
The pipeline
What happens when you push to main.
A typical pipeline we build, from a code push to production in under 90 seconds. Nothing broken gets past the test stage, and nothing reaches users without a person approving it.
-
Step 1
Push
main branch
-
Step 2
Test
PHPUnit or Jest
-
Step 3
Build
composer or npm
-
Step 4
Staging
auto-deploy
-
Step 5
Approve
manual gate
-
Step 6
Production
zero downtime
On every push
Tests run automatically. If they fail, the pipeline stops, and nothing broken reaches staging or production.
Staging deploys itself
Every passing build goes to staging. Your team reviews it there before production approval is given.
Production is gated
A production deploy needs one click of approval in GitHub Actions. No accidental production pushes.
What we set up
Six DevOps capabilities, fixed price each.
Take one or combine them. Each is scoped in writing before we start and tested end to end before handover.
GitHub Actions CI/CD pipeline
Test job, build job, staging deploy and a manual production approval gate. Secrets kept in GitHub Secrets. The YAML is documented so your team can change it.
- Test, build, deploy jobs
- Approval gate
Staging environment
A password-protected staging subdomain on your VPS with its own database, deployed on every passing build and set up to mirror production config.
- Own database
- Auto-deployed
Docker containerisation
Dockerfile and docker-compose.yml with PHP, Nginx, MySQL and Redis, so local development matches production. The pipeline builds and pushes the image on every commit.
- Matches production
- Image per commit
Server hardening and SSH
SSH key login only, root login disabled, UFW firewall, fail2ban, unattended security upgrades and a deploy user with limited permissions.
- Key-only SSH
- Firewall and fail2ban
Monitoring and alerting
Endpoint checks with UptimeRobot or Better Uptime, alerts on Slack or WhatsApp, CPU, memory and disk alerts via Netdata, and deploy notifications in your team channel.
- Downtime alerts
- Resource alerts
Zero-downtime releases
A rolling or blue-green strategy depending on your infrastructure, with database migrations written to stay backward-compatible during the switch.
- Health checks
- Instant rollback
Platforms
A pipeline shaped to your framework.
Laravel and CodeIgniter 4 are our primary targets. WordPress and Node.js deploy differently, and the pipeline follows how each one really runs.
CI/CD for Laravel
The pipeline runs your test suite, installs production dependencies, runs migrations with --force, rebuilds the config, route and view caches and reloads PHP-FPM so the new code is picked up.
# deploy steps, in order
1. php artisan test
2. composer install --no-dev --optimize-autoloader
3. php artisan migrate --force
4. php artisan optimize
5. sudo systemctl reload php8.3-fpm
CI/CD for CodeIgniter 4
CodeIgniter 4 apps get the same structure: tests, Composer install, migrations through Spark, cache cleared and PHP-FPM reloaded, with the writable folder shared between releases.
# deploy steps, in order
1. vendor/bin/phpunit
2. composer install --no-dev
3. php spark migrate --all
4. php spark cache:clear
5. sudo systemctl reload php8.3-fpm
CI/CD for WordPress
WordPress pipelines are rsync-based rather than git pull: the theme and custom plugins are versioned and synced, while uploads and wp-config stay on the server untouched.
# deploy steps, in order
1. composer install (if used)
2. npm run build (theme assets)
3. rsync theme and plugins
4. uploads and wp-config excluded
5. cache purged after deploy
CI/CD for Node.js
Node.js apps are installed from the lockfile, built, and restarted by the process manager only after the new build passes its health check.
# deploy steps, in order
1. npm ci
2. npm test
3. npm run build
4. restart the process manager
5. health check before traffic
Zero downtime
New code goes live only after it is ready.
The new release is prepared next to the running one. Traffic switches only when it passes its health check, and the previous release stays on disk, so going back is quick.
Release folders
Each deploy lands in its own folder. A symlink points to the live one.
Health check first
The switch happens only when the new release responds correctly.
Safe migrations
Schema changes written to work with both the old and the new code.
Two ways back
git revert and push in under 90 seconds, or switch the symlink in about 5 seconds.
Server hardening
A security baseline before your app arrives.
An automated deploy needs a server that only accepts what it should. These are set on every VPS we prepare, and written into the handover document.
Ask about hardening-
01
SSH key authentication only
Password login switched off, so guessed passwords are useless.
-
02
Root login disabled
Admin work goes through named users with sudo.
-
03
UFW firewall rules
Only the ports the app needs are open, typically SSH, HTTP and HTTPS.
-
04
fail2ban
Repeated failed logins get the source IP blocked.
-
05
Unattended security upgrades
Security patches for Ubuntu applied without waiting for a person.
-
06
Dedicated deploy user
The pipeline logs in as a user that can deploy and nothing more.
-
07
Server-level rate limiting
Nginx limits on the endpoints that attract abuse, such as login forms.
-
08
Cloudflare in front, where it fits
DNS, TLS and the web application firewall at the edge.
Tools we use
The DevOps stack we configure.
GitHub Actions is our primary pipeline tool. If your team already lives in GitLab or Bitbucket, we build there instead.
CI/CD
GitHub Actions
GitLab CI
Bitbucket Pipelines
Containers
Docker
Docker Compose
Container registry
Server stack
Ubuntu 24.04
Nginx
PHP-FPM
Monitoring
UptimeRobot
Better Uptime
Netdata
Security
Cloudflare WAF
fail2ban
UFW firewall
App platforms
Laravel and CI4
WordPress
Node.js
How we work
From FTP to pipeline in days.
A basic pipeline takes 1 to 2 days and a full DevOps setup 3 to 5. We start by reading how you deploy today, so nothing that works is thrown away.
-
01
Day 1
Audit your deploy
Server access, the repo (or the lack of one), environment files and every manual step done today, written down.
- Current process mapped
- Risks listed
-
02
Day 1 to 2
Git and branching
Code that only lives on the server goes into a proper repo with a simple branching model the team can follow.
- Repo set up
- Branch rules
-
03
Day 2 to 4
Pipeline and staging
Workflow YAML, secrets, staging subdomain and the approval gate, tested end to end with real deploys.
- Tested end to end
- Approval gate
-
04
Day 4 to 5
Handover
Hardening and monitoring finished, then a handover document with both rollback procedures and a walkthrough for your team.
- Rollback documented
- Team walkthrough
A typical full DevOps setup
Audit and Git
Pipeline and staging
Hardening and monitoring
Handover
Day 1Day 3Day 5
Client work
Platform and performance work we have done.
CodeIgniter 4
Role-Based Auth
CI4 Shield
JNV Sikar Alumni Association
A full public-facing alumni site plus a 3-tier role-based admin system in CI4 with Student, Super Admin, and Batch Coordinator roles.
Read the case study3 Live
User Roles
9
Admin Pages
8
Public Pages
Education / Non-Profit · CodeIgniter 4
JNV Sikar Alumni Association
3 Live user roles
Luxury Interiors / Architecture · CodeIgniter 4
Vajra Atelier
Centralised media management
Home Services · Laravel
Lykan Water Solutions
SaaS & Products · Laravel
1JobTracker
Travel & Tourism · Laravel
MakeEasyBooking
8 pages built
Heavy Equipment / Construction · CodeIgniter 4
Maluka Earthmovers
Hardened auth system
See every case study
Shopify, WordPress and custom builds, with the brief, the work and the result.
View all workPricing
Fixed price. Done once. Works for every deploy after.
A CI/CD pipeline is a one-time setup cost. Once it runs, every future deploy is automatic.
Basic Pipeline
GitHub Actions pipeline for one app. Test, then deploy to production. SSH-based, no Docker.
Rs 8K to 18K
1 to 2 days
- GitHub Actions workflow for one app
- Test job before every deploy
- SSH deploy keys and GitHub Secrets
- Rollback procedure documented
- Staging environment
- Server hardening and monitoring
- Docker containerisation
Most common
Full DevOps Setup
Pipeline, staging environment, server hardening, monitoring and a zero-downtime deploy strategy.
Rs 20K to 45K
3 to 5 days
- Everything in Basic Pipeline
- Password-protected staging environment
- Manual approval gate for production
- Server hardening (SSH keys, UFW, fail2ban)
- Uptime and resource monitoring with alerts
- Zero-downtime deploy strategy
- Docker containerisation
Docker + Full CI/CD
Full containerisation, Docker Compose local dev, image registry, CI/CD pipeline, staging and monitoring.
Rs 40K to 80K
5 to 8 days
- Everything in Full DevOps Setup
- Dockerfile and docker-compose.yml
- Local dev environment that matches production
- Image built and pushed on every commit
- Container registry set up
All prices exclusive of GST. Scoped individually: complexity varies by app and infrastructure.
Not sure which setup you need?
Describe how you deploy today. We tell you what to fix first and which plan covers it, with no obligation.
FAQ
Questions about CI/CD setup.
Not sure if your project needs this? Describe your current deploy process in the form and we will tell you what to fix first.
If your code is on GitHub and the app runs on a VPS, a basic pipeline is 1 to 2 days. We add a deploy workflow, configure SSH deploy keys, store server credentials in GitHub Secrets and test the full flow. When server access is clean and the code is already in version control, it is often a half-day job.
We mainly build GitHub Actions pipelines, but we also set up GitLab CI and Bitbucket Pipelines when your team already works there. If your code currently lives only on the server and is deployed by FTP, we first set up a proper Git repository and a simple branching strategy, then build the pipeline on top of it.
The pipeline can run without tests: the test job is skipped and the deploy goes ahead. We recommend at least a smoke test, such as a health check endpoint that must respond, as a gate. Writing a full test suite is a separate engagement, and the workflow is built so tests can be plugged in later without rebuilding it.
Yes. Laravel and CodeIgniter 4 are our primary targets. The pipeline handles Composer install, runs migrations, clears the application cache and reloads PHP-FPM. WordPress pipelines are different, rsync-based rather than git pull, and are fully supported too, as are Node.js apps.
Two ways. The quick one: git revert the bad commit and push, and the pipeline redeploys the previous code in under 90 seconds. The instant one: the previous release stays in a releases folder, so switching back is one symlink change and a PHP-FPM reload, about 5 seconds. Both are written into the handover document.
For most small and medium PHP apps on a single VPS, Docker adds complexity without much benefit. It becomes worth it when several developers need identical local setups, when you run multiple isolated apps on one server, or when you plan to scale across several servers. We recommend it based on your situation, not to grow the scope.
For anything that takes payments or enquiries, yes. Staging is where plugin updates, code changes and migrations are checked before users see them. We set it up on a password-protected subdomain with its own database, deployed automatically on every passing build, so testing costs your team no extra effort.
You do. The repository, GitHub Secrets and the server stay in your accounts, with us added as users while we work. The handover document lists every credential location, the workflow files and both rollback procedures, so your team or any other developer can run and change the pipeline without us.
Yes, through our Managed Hosting retainer: security patches, backup checks, uptime monitoring and emergency response on a fixed monthly fee. Many clients take the DevOps setup as a one-time project and the retainer after it, but the pipeline works on its own and does not require ongoing work from us.
From the blog
Reading that goes with this.
Marketing
·
8 min read
Local SEO for a Jaipur Business: Google Business Profile, Citations and the Map Pack
The map pack is ranked on three things Google names publicly, and only two of them are yours to change. Here is what that means in practice for a Jaipur business, and which of the usual local SEO advice is a waste of your time.
Shopify
·
8 min read
Moving From WooCommerce to Shopify: A Migration Checklist That Protects Your Rankings
Most of the risk in a WooCommerce to Shopify move is not the product data. It is the URL map, the things that were plugins and now have to be rebuilt, and in India the payment gateway, which does not come across at all.
Marketing
·
7 min read
eCommerce SEO for Shopify Stores in India: The Work That Actually Ranks Product Pages
Shopify handles a lot of technical SEO for you and leaves a specific set of problems it cannot fix. Here is which pages to fight for, the duplicate URL trap every store has, and what to do about supplier product copy.
Let's fix your deploys
One setup. Every deploy after it is automatic.
Push to GitHub, tests run, staging deploys, you approve, production updates. Tell us how you deploy today and we reply within 2 hours.
Free 30-minute call
We go through your current deploy process and where it is risky.
Fixed-price proposal
Scope, timeline and price in writing before any work starts.
Pipeline live in days
Tested end to end, with a handover document your team can follow.
Describe your deploy process
Your framework, where it is hosted and how you deploy now are enough to start.