DEV Community: DeployHQ

Self-Host n8n on a VPS: Docker, HTTPS, and Git-Based Updates

DeployHQ — Thu, 21 May 2026 09:40:22 +0000

Most n8n self-hosting tutorials stop at docker compose up. That gets you a running instance, but it leaves a real gap: where do your workflows live? How do you upgrade without losing them? How do you roll back a bad change? Treat your n8n server like any other application — workflows in Git, infrastructure in Docker Compose, deploys triggered from main — and self-hosting becomes a maintainable habit instead of a fragile pet project.

This guide walks through standing up n8n on a single VPS with Docker, putting it behind HTTPS, and wiring it to a DeployHQ project so every change to your workflow repo updates the server. By the end you'll have a production-ready instance with backups, version control, and one-click rollback when something goes wrong.

What you'll build

n8n running in Docker on a single Ubuntu VPS
Postgres alongside it as the data store (not SQLite — more on that below)
Nginx + Let's Encrypt in front for HTTPS on your own domain
A Git repository that holds the docker-compose.yml, environment template, and an exportable JSON copy of every workflow
DeployHQ wiring the repo to the server, so a git push to main reconfigures the stack and re-imports workflows

By the end you'll be able to develop a workflow locally (or on a staging instance), export it, commit, push, and watch DeployHQ deploy the change with rollback available if it misbehaves.

Why self-host n8n at all?

n8n Cloud is good. So why bother with a VPS?

Cost predictability. A $5-10/month VPS handles thousands of runs per day. Cloud pricing scales by execution.
Data stays on your infrastructure. Webhooks, credentials, and execution logs never leave the box.
Custom nodes. You can npm install community nodes the cloud version doesn't ship.
No execution limits. Long-running flows that hit cloud step caps just run.

The trade-off is operational ownership — you patch the OS, renew the certificate, watch the disk. Most of that is one-time setup. The rest of this guide is the one-time setup, done properly.

Prerequisites

A VPS with Ubuntu 22.04 or 24.04 and SSH access — any of Hetzner, DigitalOcean, Vultr, Linode work fine
A domain you control with an A record pointing at the VPS IP
A DeployHQ account (free trial — sign-up link at the end)
A GitHub or GitLab repository
Docker installed locally for testing

Step 1: Provision the VPS

SSH in as root, install Docker, and set up a deploy user:

ssh root@your-vps-ip
curl -fsSL https://get.docker.com | sh

adduser deploy
usermod -aG docker deploy
mkdir -p /home/deploy/n8n
chown deploy:deploy /home/deploy/n8n

From your local machine, copy your SSH key to the deploy user:

ssh-copy-id deploy@your-vps-ip

Confirm passwordless login works:

ssh deploy@your-vps-ip "docker --version"

You should see the installed Docker version. That's the account DeployHQ will use.

Step 2: The n8n Docker Compose stack

In your local repo, create docker-compose.yml:

services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
      POSTGRES_DB: ${POSTGRES_DB}
    volumes:
      - postgres_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER} -d ${POSTGRES_DB}"]
      interval: 10s
      timeout: 5s
      retries: 5

  n8n:
    image: n8nio/n8n:1.74.0 # pin to a specific tag — don't use :latest in prod
    restart: unless-stopped
    depends_on:
      postgres:
        condition: service_healthy
    ports:
      - "127.0.0.1:5678:5678" # localhost only — Nginx will proxy
    environment:
      DB_TYPE: postgresdb
      DB_POSTGRESDB_HOST: postgres
      DB_POSTGRESDB_PORT: 5432
      DB_POSTGRESDB_DATABASE: ${POSTGRES_DB}
      DB_POSTGRESDB_USER: ${POSTGRES_USER}
      DB_POSTGRESDB_PASSWORD: ${POSTGRES_PASSWORD}
      N8N_HOST: ${N8N_HOST}
      N8N_PROTOCOL: https
      N8N_PORT: 5678
      WEBHOOK_URL: https://${N8N_HOST}/
      GENERIC_TIMEZONE: ${TIMEZONE:-Europe/London}
      N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
    volumes:
      - n8n_data:/home/node/.n8n
      - ./workflows:/workflows:ro

volumes:
  postgres_data:
  n8n_data:

Four things matter here:

Postgres, not SQLite. SQLite is fine for kicking the tires. For anything you care about, Postgres handles concurrent executions, backups, and growth without complaint.
N8N_ENCRYPTION_KEY is sacred. It encrypts the credentials n8n stores in the database. Change it and every credential breaks — you'll have to re-enter every API key, OAuth token, and SSH credential. Generate it once with openssl rand -hex 32, store it in DeployHQ as a config file, and never lose it.
WEBHOOK_URL must be your public HTTPS URL. n8n bakes this into the URLs it gives webhook senders. If it's wrong, Stripe / GitHub / Slack will hit a dead address.
Port 5678 is bound to 127.0.0.1. Don't expose n8n directly to the internet — put it behind Nginx with TLS. Anyone hitting port 5678 from outside gets nothing.

Create .env.example to commit to the repo (without secrets):

POSTGRES_USER=n8n
POSTGRES_PASSWORD=
POSTGRES_DB=n8n
N8N_HOST=workflows.yourdomain.com
N8N_ENCRYPTION_KEY=
TIMEZONE=Europe/London

The real .env lives in DeployHQ's server config — never in the repo.

Step 3: Put Nginx in front with Let's Encrypt

On the VPS, install Nginx and Certbot:

sudo apt update
sudo apt install -y nginx certbot python3-certbot-nginx

Add a server block at /etc/nginx/sites-available/n8n:

server {
    server_name workflows.yourdomain.com;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:5678;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection 'upgrade';
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_cache_bypass $http_upgrade;
        proxy_read_timeout 3600; # long-running executions
        proxy_send_timeout 3600;
    }

    listen 80;
}

Enable it and run Certbot:

sudo ln -s /etc/nginx/sites-available/n8n /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx
sudo certbot --nginx -d workflows.yourdomain.com

The proxy_read_timeout 3600 is important. n8n executions can run for minutes when a workflow waits on an external API — without that, Nginx kills the connection and the run appears to fail.

Step 4: First run

Back on your local machine, commit the repo and push it to GitHub:

git init && git add . && git commit -m "Initial n8n stack"
git remote add origin git@github.com:you/n8n-stack.git
git push -u origin main

For the very first deploy, SSH into the VPS, copy the .env over (DeployHQ will manage it from here on), and bring the stack up manually:

ssh deploy@your-vps-ip
cd /home/deploy/n8n
# (DeployHQ will populate docker-compose.yml on first deploy — for now scp it manually)
docker compose up -d

Visit https://workflows.yourdomain.com, create the admin account, and you're live.

Step 5: Wire up Git-based deploys with DeployHQ

This is the part most n8n tutorials skip. In DeployHQ:

Create a new project and point it at your repo. DeployHQ supports deploying directly from a GitHub repo to your server without you wiring webhooks by hand.
Add the VPS as a server. Username deploy, port 22, deployment path /home/deploy/n8n. Use the SSH key you authorised in Step 1.
Add the .env as a config file. In the server's config-files section, create /home/deploy/n8n/.env and paste the real values (Postgres password, N8N_ENCRYPTION_KEY, N8N_HOST). DeployHQ writes this file before every deploy — your secrets stay out of Git.
Configure the deploy SSH command: bash cd /home/deploy/n8n && \ docker compose pull && \ docker compose up -d && \ docker compose exec -T n8n n8n import:workflow --input=/workflows/ --separateThis pulls any new n8n image version, recreates containers with the new Compose config, and re-imports every workflow JSON from the mounted /workflows directory.
Enable auto-deploy on push to main. Every merge now triggers a deploy.

Push a no-op change to trigger the first run. Watch the DeployHQ log — you'll see the repo transferred, the env file written, the SSH commands executed. The site shouldn't blink: docker compose up -d only recreates containers if something actually changed.

If a deploy ever breaks something, DeployHQ's one-click rollback restores the previous repo state and re-runs the deploy command — a single button, no manual Compose juggling.

Step 6: Workflows as code

This is the payoff for everything above. Instead of the workflow is whatever I last clicked in the UI, your repo becomes the source of truth.

The flow:

Develop locally or on a staging instance. A spare n8n container on your laptop works fine.
Export the workflow. In the n8n UI: open the workflow → menu → Download → save the JSON to workflows/your-workflow-name.json in your repo.
Commit and push. bash git add workflows/your-workflow-name.json git commit -m "Add: Slack-to-Sheets sync workflow" git push
DeployHQ deploys. The deploy command runs n8n import:workflow --input=/workflows/ --separate, which upserts the workflow into the database. Existing workflows with the same ID are updated; new ones are created.

A few practical notes:

One JSON file per workflow. The --separate flag tells n8n's importer to treat each file independently. Easier diffs in PRs.
Credentials are not in the JSON. n8n stores them encrypted in the database, referenced by ID. Set up credentials once in the UI; the workflow JSON just references them. This is why N8N_ENCRYPTION_KEY matters — drop it and the references become unusable.
The UI is now read-only in your head. Anyone making changes in production goes back to staging, exports, commits. Drift kills you otherwise.

The same Compose pattern works for sidecar services — drop a Python agent or a Postgres backup container into the same docker-compose.yml, and DeployHQ deploys all of it together.

Step 7: Upgrade n8n safely

n8n releases often. The temptation is to use n8nio/n8n:latest and let it ride. Don't.

With a pinned tag, upgrading becomes a one-line PR:

- image: n8nio/n8n:1.74.0
+ image: n8nio/n8n:1.78.0

Push, DeployHQ deploys, the new image is pulled, the container recreated. If anything misbehaves, hit rollback and the previous tag is back in seconds. You get a git history of every n8n version that has ever run in production — handy when a workflow stops working and you need to find what changed.

Two upgrade hygiene tips:

Read the changelog before bumping a major. n8n occasionally deprecates nodes or changes execution semantics.
Snapshot Postgres before a major. A docker compose exec postgres pg_dump ... to a file in a backup directory takes seconds and saves hours.

For deploys in general, DeployHQ runs zero downtime deployments by default — when you eventually move to a multi-server setup, the rollout pattern stays the same.

Step 8: Backups

Two things to back up:

The Postgres database. Everything important — workflows, credentials, execution history — lives here.

docker compose exec -T postgres \
  pg_dump -U n8n -d n8n --no-owner --clean \
  > backup-$(date +%F).sql

Drop a small script in your repo at scripts/backup.sh that runs this and uploads the file to S3 (or B2, or any object store). Cron it nightly on the VPS.

The n8n_data volume. Holds binary attachments and custom nodes. Tar it once a week to the same store:

docker run --rm -v n8n_n8n_data:/data -v $PWD:/backup alpine \
  tar czf /backup/n8n-data-$(date +%F).tar.gz -C /data .

The workflows themselves are already in Git, so you don't need to back those up — that's the whole point of the workflows-as-code pattern.

Where to go from here

The pillar above gets you a single-node, production-ready n8n instance with version control and rollback. From here:

Drop a custom AI service next to n8n. The same docker-compose.yml handles a sidecar Python or Node service — expose it at http://agent:8000 and have any n8n workflow hit it as a webhook. Same VPS, same deploy pipeline, no extra infrastructure.
Compare with other self-hosted agent platforms. If n8n's node-based model isn't the right fit, look at alternatives covered on the blog: Paperclip as a self-hosted agent orchestrator, OpenClaw as a self-hosted AI assistant with a Skills plugin system, and Hermes Agent for self-improving agents on a VPS.
Run agents inside CI/CD. For a different shape of the same problem — agents that act on your repository — see how AI agents fit into CI/CD pipelines from GitHub issue to production deploy.
Drive deploys from a terminal agent. If you want Claude Code, Cursor, or Codex to trigger n8n redeploys for you, the DeployHQ CLI exposes a deployment trigger your AI agent can call.

Ready to put n8n on infrastructure you control, with a Git-driven deploy pipeline behind it? Start a free DeployHQ trial and wire your first push-to-deploy n8n stack in under twenty minutes.

Questions? Email us at support@deployhq.com or find us on X at @deployhq.

PR Radar vs GitHub Notifications vs Email: How Developers Actually Track Pull Requests

DeployHQ — Fri, 24 Apr 2026 12:32:48 +0000

If you've managed more than a handful of pull requests across more than one Git platform, you've probably built your own little tracking system out of whatever was free and already installed. A few browser tabs. Email filters. Maybe a Slack integration that someone turned on two years ago and nobody can remember the auth for. It works, until it doesn't — until the PR that needed the please merge today comment gets buried under twelve identical CI notifications, or until the GitLab side of your migration stays invisible for three hours because you only had the GitHub tab open.

This is a comparison of the ways developers actually track PRs today — including PR Radar, the open-source Chrome extension we built because none of the existing options did what we wanted. We'll be honest about where each one wins and where it falls short, and we'll end with the one question that decides which tool you actually need. It's the same format we used for our package manager benchmark and our transactional email API comparison — practical, developer-to-developer, and honest about the gaps.

The five options on the table

Before the comparison, here's the shortlist. We've stayed focused on tools that monitor PR status rather than tools that try to change your PR workflow (so Graphite, Aviator, and Reviewpad are out — they solve a different problem).

Email notifications — the default for GitHub, GitLab, and Bitbucket
GitHub's built-in notification inbox — the bell icon, the /notifications page
Slack integrations — GitHub for Slack, GitLab for Slack, Bitbucket's bot
GitHub-specific extensions — Refined GitHub, Notifier for GitHub
PR Radar — multi-platform dashboard in the browser toolbar

Option 1: Email — the default everyone ignores

Every Git host turns on email notifications by default. Every developer turns most of them off within a month.

The problem with email isn't that it's a bad channel. It's that PR events are high-frequency and low-information per message. A typical active PR generates email for:

The initial open
Every review comment
Every reply in a thread
Every push that re-triggers CI
Every CI status change
Merge or close

Multiply by 8–12 active PRs in a normal week and you've built a firehose. The signal-to-noise ratio collapses because every email looks roughly the same in the preview pane: a PR title, a repo name, and one line of context. You cannot tell at a glance which of your fifteen unread messages is CI failed on the PR that's blocking release and which is approving nit on a docs typo.

Where email wins: Audit trail. If you need a durable record of what happened and when, email is it. Good for compliance, useless for real-time awareness.

Where it fails: Real-time awareness, cross-platform visibility, CI status at a glance.

Option 2: GitHub's notification inbox

GitHub's inbox (the bell icon and /notifications) is better than email for one reason: it's scoped and threaded. A single PR becomes one inbox entry that updates in place instead of twenty separate emails.

It has genuine improvements over the last couple of years — filters, custom views, Participating vs All, per-repo mute. If you live entirely inside GitHub, the inbox is solid.

But it has three hard ceilings.

It's GitHub-only. If your team uses GitLab for infra and GitHub for apps, the inbox solves half your problem. The other half you track… somehow.

It doesn't show CI status inline. The inbox will tell you CI ran on this PR. It will not tell you whether it passed or failed without a click into the PR page. For a tool whose primary job is telling you what needs your attention, burying the pass/fail state behind a click is a miss.

It needs a tab open. The inbox icon lives inside github.com. If you closed the tab during a focus block, you find out about a failed deploy the next time you cmd-T your way back. Browser desktop notifications exist but are disabled by default and, even when on, only fire when a GitHub tab is already open.

Where it wins: Native, reliable, no extra auth, granular filters.

Where it fails: GitHub-only, no CI status in the list view, tab-bound.

Option 3: Slack integrations

Slack is where most engineering teams already are, so routing PR events into Slack seems obvious. And for a few specific use cases — a dedicated #deploys channel, a release-critical PR that the whole team is watching — it's the right tool.

For everyday PR tracking, Slack is a noise amplifier. A rebase-heavy afternoon on a single PR can push twenty notifications into a channel. The team stops reading them. Important signals (production deploy failed) end up in the same channel as unimportant ones (renovate bumped a patch version), with the same visual weight, both probably muted by Thursday.

There's also a coverage asymmetry. GitHub for Slack is mature. GitLab for Slack is functional. Bitbucket's Slack integration exists but feels like an afterthought. If you've got repos on all three, Slack gives you an uneven view of each one.

Where it wins: Team visibility on critical events, shared context during an incident.

Where it fails: Personal PR tracking, signal-to-noise, multi-platform parity.

Option 4: Refined GitHub and Notifier for GitHub

If you've looked for browser extensions for this before, you've hit two classic options.

Refined GitHub is excellent — dozens of polish-level improvements to github.com pages. But it enhances GitHub; it doesn't pull PR status out of GitHub into your toolbar. You still need to open the tab.

Notifier for GitHub does put a badge in your toolbar, but the badge counts unread notifications — not CI state, not review state. A red badge tells you there's something and nothing else. You click through to find out what.

Both are GitHub-only, both assume GitHub is your whole world, and neither addresses the core visibility problem if your work spans platforms.

Where they win: Free, lightweight, GitHub UX polish (Refined GitHub in particular is a staple).

Where they fail: Single-platform, no CI awareness in Notifier, no toolbar summary in Refined.

Option 5: PR Radar

PR Radar is the extension we built after rotating through all four options above and still ending up with a browser window full of tabs. It's a Chrome extension (Firefox and Edge in progress), MIT-licensed, open source, and free — no paid tier, no accounts, no backend at all. Links to the store listing and repo are at the end of the post.

The short version of what it does:

One toolbar popup with every open PR across GitHub, GitLab, and Bitbucket
Badge on the toolbar icon with a live pass / fail / running count for CI
Unresolved comment count per PR, pulled via GraphQL so the number is actually correct
Deployment status inline with clickable environment URLs
Desktop notifications and sound alerts when CI finishes (no tab required — it polls in a service worker)
One-click merge from the dashboard, across all three platforms
Stale PR dimming with a configurable threshold so your attention goes to the active ones
Keyboard shortcuts — j/k to move between PRs, o to open, / to search, ? for the full list

The design goal was minimum cognitive load: glance at the toolbar, see whether anything needs you, go back to what you were doing. If the badge is green, there is nothing to do. If it's red, you know exactly where to look. The same mindset drove our list of developer CLIs that AI agents use well — a good dev tool should compress ten decisions into one glance.

Privacy-wise, PR Radar doesn't send your tokens anywhere. Your personal access tokens sit in the browser's local storage, and the extension makes API calls directly from your browser to each Git platform. There is no PR Radar backend. We don't run analytics. There's no DeployHQ account required — the extension works whether or not you're a DeployHQ customer.

Side-by-side

Dimension	Email	GitHub Inbox	Slack	Refined / Notifier	PR Radar
GitHub	✅	✅	✅	✅	✅
GitLab	✅ (via email)	❌	⚠️ Uneven	❌	✅
Bitbucket	✅ (via email)	❌	⚠️ Uneven	❌	✅
CI status at a glance	❌	❌	⚠️ In channel	❌	✅ Badge + inline
Unresolved comment count	❌	❌	❌	❌	✅
Deploy status in PR list	❌	❌	❌	❌	✅
Works without a tab open	✅	❌	✅	❌	✅ Service worker
Sound / desktop alerts	❌	⚠️ If tab open	✅	❌	✅
Merge from the tool	❌	❌	❌	❌	✅ All 3 platforms
Cost	Free	Free	Free tier + Slack cost	Free	Free + open source
Privacy	Platform stores email	Platform	Slack + platform	Platform	100% local, no backend

The pattern is consistent: each mainstream option handles one or two of these well and treats the rest as out of scope. For developers who only use GitHub and already live in Slack, that's fine. For anyone working across platforms, the gaps add up fast.

The deployment connection

If you're reading this on the DeployHQ blog, there's a fair chance you care specifically about the last mile: the moment between CI passed and change is live. That moment is where PR tracking stops being a productivity nice-to-have and starts being a deployment-quality thing.

Two concrete examples:

Catching a broken deploy before the channel sees it. When CI includes a deploy step (either an automatic deployment from Git or a preview environment triggered by PR), the failure signal travels through the same notification pipes as every other CI event. In email or Slack, a failed deploy looks like every other failed check. In PR Radar, the toolbar flips red the moment the job changes state, with the deploy URL one click away. That's a four-second feedback loop instead of a forty-minute one.

Merging without a tab full of PRs. DeployHQ's one-click rollback and zero-downtime deployments are designed to make shipping cheap. The bottleneck in that flow is usually human: somebody has to decide the PR is ready and hit merge. If that decision point lives in a popup rather than on a PR page buried in a tab group, the whole cycle tightens.

Neither of these is the reason to install a browser extension on its own. But if you already care enough about deployment velocity to be reading this, the PR tracking side of the workflow probably deserves the same attention you've given your CI/CD pipeline and your deploy automation.

Who should pick which

Here's the actual decision tree.

You only use GitHub and you're fine with the inbox. Stay with it, maybe bolt on Refined GitHub for UI polish. No extension needed.

You only use GitHub but the inbox feels lossy. Try Notifier for GitHub for the toolbar badge. If you want CI status specifically and not just unread counts, PR Radar fits even in single-platform setups.

You use GitHub + GitLab or GitHub + Bitbucket. This is the case email, the inbox, and GitHub-specific extensions all fail at. A dedicated multi-platform tool is the only real answer. PR Radar is the one we built; there isn't much direct competition in the free / privacy-first slice of that category.

You're a team lead who wants team-wide visibility into deploys. Slack is still right for that — route release-critical events into a dedicated channel. Just don't try to use the same Slack integration for personal PR tracking; it's the wrong tool for the wrong granularity.

You care about privacy or you work on client repos with sensitive PR titles. PR Radar keeps everything local — tokens in browser storage, API calls direct to platforms, no backend, no analytics. Hosted PR tools generally require you to authorize an OAuth app that sees your PR content. That's a real trade-off worth knowing about, in the same category as picking which MCP servers you grant access to your codebase or how you wire Claude Code into Git.

Try it

PR Radar is free, open source (MIT), and takes about a minute to set up.

Install from the Chrome Web Store (Firefox and Edge builds are in progress on the GitHub releases page)
Star the repo on GitHub if it saves you a tab — it's how we know to keep investing in it
File an issue if a platform quirk breaks your setup; we read all of them

If you're already on DeployHQ, PR Radar closes the visibility gap between PR looks good and change is live without asking you to change anything about your deployment workflow. If you're not, it's still the fastest way we've found to stop tab-hopping between Git hosts.

Questions, platform-specific gotchas, or feature requests? Email us at support@deployhq.com or ping us on Twitter/X. If you'd rather build your own PR dashboard on top of the GraphQL APIs, the source is MIT-licensed and PRs are welcome.

SQLite vs PostgreSQL vs MySQL: Choosing the Right Database

DeployHQ — Thu, 02 Apr 2026 06:31:57 +0000

Every application stores data somewhere, and for most web applications, that means a relational database. But which one? SQLite, PostgreSQL, and MySQL serve very different use cases despite sharing SQL as their query language.

This guide compares all three with honest benchmarks, real configuration differences, and practical advice for choosing the right database for your project and deployment workflow.

Quick Comparison

Feature	SQLite	PostgreSQL	MySQL
Type	Embedded (serverless)	Client-server	Client-server
Storage	Single file	Server with data directory	Server with data directory
Setup	Zero configuration	Install + configure	Install + configure
Concurrent writes	Limited (file-level locking)	Excellent (MVCC)	Good (row-level locking with InnoDB)
Max database size	~281 TB (theoretical)	Unlimited	Unlimited
JSON support	Basic (json functions)	Advanced (JSONB with indexing)	JSON type with functions
Full-text search	FTS5 extension	Built-in (ts_vector)	Built-in (InnoDB)
Replication	None	Streaming + logical	Primary-replica, Group Replication
Best for	Small apps, development, embedded	Complex apps, data integrity	Web apps, read-heavy workloads

SQLite: The Embedded Database

SQLite isn't a server — it's a library that reads and writes directly to a single file on disk. There's no installation, no configuration, no separate process. Your application links against the SQLite library and talks directly to the database file.

Strengths

Zero configuration : No server to install, configure, or maintain
Single file : The entire database is one .sqlite or .db file — easy to copy, backup, and move
Self-contained : No external dependencies
Reliable : Used in every smartphone (iOS and Android), every web browser, and most operating systems
Fast for reads : No network overhead since it's in-process

Limitations

Concurrent writes : Only one writer at a time (readers can run concurrently). WAL mode improves this but doesn't match PostgreSQL
No user management : No built-in authentication or access control
Limited ALTER TABLE : Can't drop or rename columns in older versions (improved in 3.35.0+)
No network access : The database file must be on the same machine as the application

When to Use SQLite

Development and prototyping : Get started without setting up a database server
Small-to-medium applications : Blogs, internal tools, single-server apps
Mobile and desktop apps : The database ships with the application
Embedded systems : IoT devices, configuration stores
Testing : In-memory SQLite databases run tests fast with no cleanup

Configuration Example

import sqlite3

conn = sqlite3.connect('app.db')
cursor = conn.cursor()

cursor.execute('''
    CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        email TEXT UNIQUE NOT NULL,
        name TEXT NOT NULL,
        created_at TEXT DEFAULT CURRENT_TIMESTAMP
    )
''')

PostgreSQL: The Enterprise Database

PostgreSQL is the most feature-rich open-source database. It emphasizes data integrity, SQL standards compliance, and extensibility. It handles complex queries, large datasets, and high-concurrency workloads.

Strengths

Data integrity : Strict type checking, ACID compliance, foreign key enforcement
Advanced features : JSONB, full-text search, window functions, CTEs, materialized views
Extensibility : Custom types, functions, operators, and extensions (PostGIS, pgvector, TimescaleDB)
Concurrency : MVCC (Multi-Version Concurrency Control) handles many concurrent writers efficiently
SQL standards : Most standards-compliant open-source database

Limitations

Setup complexity : Requires installation, configuration, and ongoing maintenance
Resource usage : Higher memory and CPU usage than SQLite or MySQL for simple workloads
Shared hosting : Less commonly available on basic hosting plans
Learning curve : Advanced features require deeper PostgreSQL knowledge

When to Use PostgreSQL

Complex applications : Apps with complex queries, relationships, and data integrity requirements
Analytics and reporting : Window functions, CTEs, and materialized views
Geospatial data : PostGIS extension is the gold standard
JSON-heavy workloads : JSONB with GIN indexes is powerful
High-concurrency writes : MVCC handles many concurrent writers well

Configuration Example

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    email TEXT UNIQUE NOT NULL,
    name TEXT NOT NULL,
    metadata JSONB DEFAULT '{}',
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- GIN index on JSONB for fast queries
CREATE INDEX idx_users_metadata ON users USING GIN (metadata);

-- Full-text search
ALTER TABLE users ADD COLUMN search_vector tsvector;
CREATE INDEX idx_users_search ON users USING GIN (search_vector);

MySQL: The Web Database

MySQL (and its fork MariaDB) has been the default database for web applications since the early 2000s. It's the M in LAMP (Linux, Apache, MySQL, PHP) and remains the most widely deployed database in web hosting.

Strengths

Ubiquity : Available on virtually every hosting platform, including shared hosting
Read performance : Optimized for read-heavy web workloads
Replication : Mature primary-replica replication for scaling reads
Ecosystem : Massive community, extensive tooling, widespread ORM support
WordPress : Powers 40%+ of the web through WordPress

Limitations

Less strict by default : Older versions silently truncate data or accept invalid dates — modern versions (8.0+) improved this significantly
Fewer advanced features : No native JSONB indexing (until recently), limited window function support in older versions
Storage engine complexity : InnoDB vs MyISAM distinction can confuse beginners

When to Use MySQL

Web applications : Traditional LAMP/LEMP stack applications
WordPress sites : WordPress requires MySQL (or MariaDB)
Read-heavy workloads : MySQL excels at simple SELECT queries at scale
Shared hosting : When it's the only database available
Legacy systems : Migrating away from MySQL is often more work than staying

Configuration Example

CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    email VARCHAR(255) UNIQUE NOT NULL,
    name VARCHAR(255) NOT NULL,
    metadata JSON,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

SQL Syntax Differences

Despite all three using SQL, there are syntax differences that matter when writing queries or switching databases:

Feature	SQLite	PostgreSQL	MySQL
Auto-increment	`AUTOINCREMENT`	`SERIAL` or `GENERATED ALWAYS`	`AUTO_INCREMENT`
Boolean type	Integer (0/1)	Native `BOOLEAN`	`TINYINT(1)`
String concat	`\	\	`
Current time	`CURRENT_TIMESTAMP`	`NOW()`	`NOW()`
UPSERT	`INSERT OR REPLACE`	`ON CONFLICT DO UPDATE`	`ON DUPLICATE KEY UPDATE`
LIMIT with offset	`LIMIT n OFFSET m`	`LIMIT n OFFSET m`	`LIMIT m, n` or `LIMIT n OFFSET m`

ORMs like Prisma, SQLAlchemy, Django ORM, and ActiveRecord abstract these differences, letting you switch databases without rewriting queries (in theory — in practice, database-specific features often creep in).

How Database Choice Affects Deployment

Your database choice has direct implications for how you deploy and manage your application:

SQLite Deployments

SQLite's database file lives alongside your application code. This creates a unique deployment challenge:

your-app/
├── app.js
├── database.sqlite ← This is your database
├── package.json
└── ...

When deploying with DeployHQ, you need to be careful:

Don't overwrite the database on every deploy. Exclude *.sqlite and *.db from your deployment or use DeployHQ's excluded files feature
Backups are simple : Just copy the file
No connection string needed : The file path is the connection

PostgreSQL and MySQL Deployments

These databases run as separate servers. Your application connects via a connection string:

# PostgreSQL
DATABASE_URL=postgres://user:password@db-server:5432/myapp

# MySQL
DATABASE_URL=mysql://user:password@db-server:3306/myapp

Store these connection strings as environment variables — never hardcode them. DeployHQ's build pipelines can inject these securely during deployment.

Migrations

All three databases need schema migrations as your application evolves. Run migrations as part of your deployment:

# In your DeployHQ build command
npm ci
npm run build
npm run db:migrate

Whether you push from GitHub or GitLab, DeployHQ runs your build commands (including migrations) before transferring files to the server.

For agencies managing client databases, PostgreSQL and MySQL offer user-level access control — you can give each client's app its own database user with restricted permissions.

FAQ

Can I start with SQLite and migrate to PostgreSQL later? Yes, if you use an ORM. The ORM abstracts SQL differences, making the switch mostly painless. Test thoroughly — there are always edge cases with date handling, string comparison, and JSON support.

Which database is fastest? It depends on the workload. SQLite is fastest for single-user read-heavy applications (no network overhead). PostgreSQL handles concurrent writes best. MySQL is optimized for simple read queries at scale. Benchmark your actual workload rather than relying on generic benchmarks.

Do I need PostgreSQL for a simple blog? No. SQLite or MySQL are fine for simple applications. Choose PostgreSQL when you need advanced features like JSONB, full-text search, or complex analytical queries.

Is MariaDB the same as MySQL? MariaDB forked from MySQL in 2009 and is largely compatible. Most MySQL applications work with MariaDB without changes. MariaDB has diverged more in recent versions, adding unique features, but the core SQL and wire protocol remain compatible.

Which database does DeployHQ recommend?DeployHQ works with any database — it deploys your application code, and your application connects to whatever database you've set up. For new projects, PostgreSQL is the most versatile choice.

There's no universally best database — only the right one for your project. SQLite for simplicity, PostgreSQL for power, MySQL for ubiquity. Pick the one that matches your needs and deploy it confidently.

Try DeployHQ free — deploy your application with any database and manage connection strings securely. See pricing for team plans.

Questions? Reach out at support@deployhq.com or @deployhq.

Nginx vs Apache vs Caddy: Choosing the Right Web Server

DeployHQ — Wed, 01 Apr 2026 13:45:21 +0000

Every web application needs a web server to handle HTTP requests. Whether you're serving a static site, reverse-proxying to a Node.js backend, or hosting a WordPress installation, your choice of web server affects performance, security, and how much time you spend on configuration.

This guide compares the three most popular options — Nginx, Apache, and Caddy — with real configuration examples and practical advice for choosing the right one.

Quick Comparison

Feature	Nginx	Apache	Caddy
Architecture	Event-driven, async	Process/thread per connection	Event-driven, Go goroutines
Performance	Excellent for static files and high concurrency	Good, but higher memory under load	Very good, slightly behind Nginx
Configuration	`nginx.conf` (custom syntax)	`httpd.conf` + `.htaccess` (XML-like)	`Caddyfile` (minimal, human-readable)
HTTPS	Manual (Let's Encrypt + certbot)	Manual (Let's Encrypt + certbot)	Automatic (built-in ACME)
Per-directory config	No (centralized only)	Yes (`.htaccess`)	No (centralized only)
Module system	Compiled modules	Dynamic modules (loaded at runtime)	Plugins (Go modules)
Market share	~34% (most popular)	~29% (declining)	~1% (growing fast)
Best for	High-traffic sites, reverse proxy	Shared hosting, PHP apps	Small-to-medium sites, automatic HTTPS

Nginx

Nginx (pronounced engine-x) was created in 2004 to solve the C10K problem — handling 10,000 concurrent connections. Its event-driven architecture uses a small number of worker processes, each handling thousands of connections asynchronously.

Strengths

Performance : Serves static files extremely fast with minimal memory
Reverse proxy : The de facto standard for proxying to application servers (Node.js, Python, Ruby, Go)
Load balancing : Built-in upstream balancing with multiple algorithms
Low memory footprint : Handles thousands of connections with minimal RAM

Configuration Example

Serving a static site:

server {
    listen 80;
    server_name example.com;
    root /var/www/example.com;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }

    # Cache static assets
    location ~* \.(css|js|png|jpg|gif|ico)$ {
        expires 30d;
        add_header Cache-Control "public, immutable";
    }
}

Reverse proxy to a Node.js app:

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

When to Use Nginx

High-traffic websites needing maximum performance
Reverse proxying to application servers
VPS deployments where you control the server
Load balancing across multiple backends
Serving static assets alongside dynamic applications

Apache

Apache HTTP Server has been running the web since 1995. It introduced the concept of dynamically loadable modules and per-directory configuration via .htaccess files — features that made shared hosting possible.

Strengths

.htaccess support : Per-directory configuration without server restart
Module ecosystem : Hundreds of modules (mod_php, mod_rewrite, mod_security)
Shared hosting : Still the default on most shared hosting providers
Documentation : Decades of community knowledge and tutorials

Configuration Example

Serving a static site:

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /var/www/example.com

    <Directory /var/www/example.com>
        Options -Indexes +FollowSymLinks
        AllowOverride All
        Require all granted
    </Directory>

    # Cache static assets
    <FilesMatch "\.(css|js|png|jpg|gif|ico)$">
        ExpiresActive On
        ExpiresDefault "access plus 30 days"
        Header set Cache-Control "public, immutable"
    </FilesMatch>
</VirtualHost>

Reverse proxy to a Node.js app:

<VirtualHost *:80>
    ServerName api.example.com

    ProxyPreserveHost On
    ProxyPass / http://127.0.0.1:3000/
    ProxyPassReverse / http://127.0.0.1:3000/

    RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>

When to Use Apache

Shared hosting environments where Nginx isn't available
PHP applications that benefit from mod_php
Projects that need .htaccess for per-directory configuration
Legacy applications with existing Apache configurations

Caddy

Caddy (v2, released 2020) is the newest of the three. Its headline feature is automatic HTTPS — it obtains and renews TLS certificates from Let's Encrypt without any configuration. The Caddyfile syntax is designed to be as simple as possible.

Strengths

Automatic HTTPS : Certificates obtained and renewed automatically via ACME
Simple configuration : A basic site takes 2-3 lines
Modern defaults : HTTP/2, HTTP/3, TLS 1.3 out of the box
Single binary : No dependencies, easy to install and update

Configuration Example

Serving a static site (with automatic HTTPS):

example.com {
    root * /var/www/example.com
    file_server
}

That's it. Caddy automatically obtains a TLS certificate, redirects HTTP to HTTPS, and serves the files.

Reverse proxy to a Node.js app:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

When to Use Caddy

Small-to-medium sites where simplicity matters
Projects where automatic HTTPS saves significant ops time
Development environments needing local HTTPS
APIs and microservices with straightforward routing

Performance Comparison

For static file serving and high concurrency, Nginx leads. Apache's process-per-connection model uses more memory under load. Caddy performs well but sits between the two.

Metric	Nginx	Apache	Caddy
Static file throughput	Highest	Moderate	High
Memory per 10K connections	~2.5 MB	~10+ MB (prefork)	~5 MB
Concurrent connection handling	Excellent	Good (with worker MPM)	Very good
TLS handshake overhead	Low (with tuning)	Low (with tuning)	Low (default)

In practice, the web server is rarely the bottleneck. Your application code, database queries, and network latency have far more impact on user-perceived performance.

How Web Server Choice Affects Deployment

When you deploy with DeployHQ, your code is transferred to the server — the web server configuration ships alongside it. Understanding the relationship between your application code and web server is important:

Configuration files deploy with your code. Your nginx.conf, .htaccess, or Caddyfile lives in your Git repository and deploys automatically when you push from GitHub or GitLab
Server restart may be needed. After deploying Nginx or Apache config changes, you often need a reload command. DeployHQ's build pipelines can run post-deploy commands to handle this
The web server is already running. DeployHQ deploys your application code. The web server itself is installed and managed separately on your server

For teams managing multiple client sites, having a consistent web server across projects simplifies operations. Agencies often standardize on Nginx for its performance and flexibility.

FAQ

Can I run Nginx and Apache together? Yes. A common pattern is Nginx as a reverse proxy in front of Apache. Nginx handles static files and SSL termination; Apache handles PHP via mod_php. This gives you the best of both worlds.

Is Caddy production-ready? Yes. Caddy v2 is stable and used in production by many companies. Its automatic certificate management actually reduces ops risk compared to manual cert renewal.

Which is best for WordPress? Apache is the traditional choice because WordPress relies on .htaccess for URL rewriting. However, Nginx works well with WordPress using a try_files directive, and many high-traffic WordPress sites run on Nginx.

Do I need a web server if I'm using Node.js/Express? Node.js can serve HTTP directly, but a reverse proxy (typically Nginx or Caddy) in front of it provides SSL termination, static file serving, load balancing, and protection against slow clients. For production, always use a reverse proxy.

Which web server is easiest to learn? Caddy, by a wide margin. A functional Caddyfile can be 3 lines. Nginx has a moderate learning curve. Apache's configuration is the most verbose but extremely well-documented.

Your web server is the front door to your application. Whether you choose Nginx for performance, Apache for compatibility, or Caddy for simplicity, the important thing is that your deployment pipeline handles the configuration reliably.

Try DeployHQ free — deploy your web server configuration alongside your application code on every push. See pricing for team plans.

Questions? Reach out at support@deployhq.com or @deployhq.

Understanding CORS: The Developer's Guide

DeployHQ — Mon, 30 Mar 2026 06:22:41 +0000

If you've ever opened your browser console and seen a red error message about CORS policy, you're not alone. CORS errors are one of the most common and most frustrating issues in web development — and they almost always surface after deployment, not during local development.

This guide explains what CORS is, why browsers enforce it, and how to fix it in every major framework.

What Is CORS?

CORS stands for Cross-Origin Resource Sharing. It's a security mechanism built into web browsers that controls which websites can make requests to your server.

When your frontend at https://app.example.com tries to fetch data from https://api.example.com, the browser checks whether the API server explicitly allows requests from app.example.com. If the server doesn't say yes, the browser blocks the response.

This isn't your server rejecting the request — the server processes it normally. The browser blocks the response from reaching your JavaScript code.

The Same-Origin Policy

CORS is built on top of the Same-Origin Policy, which defines what counts as the same origin:

https://app.example.com:443/page
  ↑ ↑ ↑
protocol domain port

Two URLs have the same origin only if all three parts match:

URL A	URL B	Same origin?	Why
`https://app.example.com`	`https://app.example.com/api`	Yes	Same protocol, domain, port
`https://app.example.com`	`http://app.example.com`	No	Different protocol
`https://app.example.com`	`https://api.example.com`	No	Different subdomain
`https://app.example.com`	`https://app.example.com:8080`	No	Different port

When origins don't match, the browser requires CORS headers from the server before it will allow the response through.

Simple Requests vs Preflight Requests

Not all cross-origin requests are handled the same way.

Simple Requests

The browser sends the request directly if it meets all of these conditions:

Method is GET, HEAD, or POST
Only standard headers (Accept, Content-Type, Content-Language)
Content-Type is application/x-www-form-urlencoded, multipart/form-data, or text/plain

For simple requests, the browser sends the request and checks the CORS headers in the response.

Preflight Requests

For anything else — PUT, DELETE, PATCH, custom headers, Content-Type: application/json — the browser sends a preflight OPTIONS request first:

Browser → OPTIONS /api/users (preflight)
Server → 200 OK + CORS headers
Browser → PUT /api/users (actual request)
Server → 200 OK + data


sequenceDiagram
    Browser->>Server: OPTIONS /api/users (preflight)
    Server-->>Browser: 200 OK + CORS headers
    Browser->>Server: PUT /api/users (actual request)
    Server-->>Browser: 200 OK + response data

The preflight asks: Am I allowed to make this type of request? If the server responds with the right headers, the browser proceeds with the actual request.

CORS Headers Explained

Access-Control-Allow-Origin

The most important header. It tells the browser which origins can access the response:

Access-Control-Allow-Origin: https://app.example.com

Or allow any origin (use with caution):

Access-Control-Allow-Origin: *

Important : You can only specify one origin or *. You cannot list multiple origins. To support multiple origins, your server must check the request's Origin header and echo it back if it's in your allowed list.

Access-Control-Allow-Methods

Which HTTP methods are permitted:

Access-Control-Allow-Methods: GET, POST, PUT, DELETE, PATCH

Access-Control-Allow-Headers

Which request headers are permitted:

Access-Control-Allow-Headers: Content-Type, Authorization, X-Requested-With

Access-Control-Allow-Credentials

Whether the browser should send cookies and authentication:

Access-Control-Allow-Credentials: true

Critical : When this is true, Access-Control-Allow-Origin cannot be *. You must specify the exact origin.

Access-Control-Max-Age

How long (in seconds) the browser caches the preflight response:

Access-Control-Max-Age: 86400

This avoids sending a preflight OPTIONS request before every actual request. Set it to 24 hours (86400) for production.

Access-Control-Expose-Headers

Which response headers JavaScript can read (beyond the basic set):

Access-Control-Expose-Headers: X-Total-Count, X-Request-Id

How to Enable CORS

Node.js / Express

The cors middleware is the standard approach:

npm install cors


const express = require('express');
const cors = require('cors');
const app = express();

// Allow specific origin
app.use(cors({
  origin: 'https://app.example.com',
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization'],
  credentials: true,
  maxAge: 86400
}));

// Or allow multiple origins
app.use(cors({
  origin: ['https://app.example.com', 'https://staging.example.com'],
  credentials: true
}));

Python / Django

Install django-cors-headers:

pip install django-cors-headers


# settings.py
INSTALLED_APPS = [
    'corsheaders',
    # ...
]

MIDDLEWARE = [
    'corsheaders.middleware.CorsMiddleware', # Must be before CommonMiddleware
    'django.middleware.common.CommonMiddleware',
    # ...
]

CORS_ALLOWED_ORIGINS = [
    'https://app.example.com',
    'https://staging.example.com',
]

CORS_ALLOW_CREDENTIALS = True

Python / Flask

pip install flask-cors


from flask import Flask
from flask_cors import CORS

app = Flask( __name__ )
CORS(app, origins=['https://app.example.com'], supports_credentials=True)

Ruby on Rails

Add rack-cors to your Gemfile:

gem 'rack-cors'


# config/initializers/cors.rb
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins 'https://app.example.com'
    resource '*',
      headers: :any,
      methods: [:get, :post, :put, :patch, :delete, :options],
      credentials: true,
      max_age: 86400
  end
end

PHP (Manual Headers)

<?php
$allowed_origin = 'https://app.example.com';

if (isset($_SERVER['HTTP_ORIGIN']) && $_SERVER['HTTP_ORIGIN'] === $allowed_origin) {
    header("Access-Control-Allow-Origin: $allowed_origin");
    header("Access-Control-Allow-Methods: GET, POST, PUT, DELETE");
    header("Access-Control-Allow-Headers: Content-Type, Authorization");
    header("Access-Control-Allow-Credentials: true");
    header("Access-Control-Max-Age: 86400");
}

// Handle preflight
if ($_SERVER['REQUEST_METHOD'] === 'OPTIONS') {
    http_response_code(204);
    exit;
}

Nginx (Server-Level)

server {
    listen 80;
    server_name api.example.com;

    location / {
        # Handle preflight
        if ($request_method = 'OPTIONS') {
            add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
            add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE';
            add_header 'Access-Control-Allow-Headers' 'Content-Type, Authorization';
            add_header 'Access-Control-Max-Age' 86400;
            add_header 'Content-Length' 0;
            return 204;
        }

        add_header 'Access-Control-Allow-Origin' 'https://app.example.com';
        add_header 'Access-Control-Allow-Credentials' 'true';

        proxy_pass http://127.0.0.1:3000;
    }
}

Common CORS Errors and Fixes

No 'Access-Control-Allow-Origin' header is present

The server isn't sending CORS headers. Add the appropriate middleware or headers for your framework.

The value of the 'Access-Control-Allow-Origin' header must not be the wildcard '*' when the request's credentials mode is 'include'

You're using credentials: true (or withCredentials: true in fetch/axios) but the server is responding with Access-Control-Allow-Origin: *. You must specify the exact origin:

// Wrong
res.header('Access-Control-Allow-Origin', '*');

// Correct
res.header('Access-Control-Allow-Origin', 'https://app.example.com');

Preflight Failures (OPTIONS Returns 405 or 404)

Your server doesn't handle OPTIONS requests. Some frameworks need explicit configuration:

// Express: cors middleware handles this automatically
// Without cors middleware, add:
app.options('*', (req, res) => {
  res.header('Access-Control-Allow-Origin', 'https://app.example.com');
  res.header('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.header('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.sendStatus(204);
});

CORS Works Locally but Fails in Production

This is the most common deployment issue. Locally, your frontend and API often run on localhost (same origin or with a dev proxy). In production, they're on different subdomains.

Check that your production server's CORS configuration includes your production frontend URL, not just localhost:3000.

CORS in Development vs Production

Development

During development, CORS issues are often avoided with a dev proxy. Most frontend tools support this:

Vite:

// vite.config.js
export default {
  server: {
    proxy: {
      '/api': 'http://localhost:3000'
    }
  }
}

The proxy makes API requests appear same-origin during development, bypassing CORS entirely.

Production

In production, you have several options:

Same origin : Serve frontend and API from the same domain (no CORS needed)
CORS headers : Configure your API to accept requests from your frontend's origin
Reverse proxy : Use Nginx to serve both frontend and API from the same domain

Option 3 is often the simplest. If your frontend and API are both deployed via DeployHQ, an Nginx reverse proxy can route /api/* to your backend and everything else to your frontend — making them the same origin.

How This Relates to Deployment

CORS issues are deployment issues. They rarely appear during development (because of dev proxies or same-origin localhost) and almost always appear when code hits staging or production.

When you deploy with DeployHQ from GitHub or GitLab:

Your CORS configuration deploys with your code — it's part of your application's middleware or server config
Environment-specific origins can be managed via DeployHQ's build pipelines — set CORS_ORIGIN as a build variable that differs between staging and production
Nginx config deploys alongside your app — your reverse proxy rules are version-controlled and auto-deployed

For agencies deploying frontend and backend separately for clients, getting CORS right from the start saves hours of debugging post-deploy.

Security Considerations

Never use * in production for APIs that handle authentication. It allows any website to make requests to your API
Validate origins : Don't blindly echo the Origin header. Maintain a whitelist of allowed origins
Don't confuse CORS with authentication. CORS controls which websites can talk to your API. It doesn't replace API authentication (tokens, sessions)
Credentials require specific origins. If you use cookies or auth headers, you must specify exact origins — * is not allowed

FAQ

Does CORS apply to server-to-server requests? No. CORS is a browser-only mechanism. Server-to-server HTTP requests (curl, fetch from Node.js, Python requests) are not subject to CORS restrictions.

Can I disable CORS in the browser? Yes, for testing — but never in production. Chrome can be launched with --disable-web-security, but this is dangerous and only for debugging.

Does CORS protect my API from abuse? No. CORS is enforced by browsers, not servers. Anyone can use curl or Postman to make requests directly. Use authentication and rate limiting to protect your API.

Why does my API work in Postman but not in the browser? Postman doesn't enforce CORS — it's not a browser. The same request that fails in the browser due to CORS will succeed in Postman because there's no same-origin policy to enforce.

Should I handle CORS in my application or in Nginx? Either works. Application-level CORS (Express cors middleware, Django cors-headers) is more flexible and portable. Nginx-level CORS is useful when you can't modify the application. Don't configure CORS in both places — the headers can conflict.

CORS is confusing at first, but it's simple once you understand the flow: the browser asks the server for permission, the server responds with headers, and the browser enforces the result. Get your headers right, test on staging before production, and you'll never see that red console error again.

Try DeployHQ free — deploy your frontend and backend together with consistent CORS configuration. See pricing for team plans.

Questions? Reach out at support@deployhq.com or @deployhq.

How To Deploy from Windows Using WSL2, Docker, and DeployHQ

DeployHQ — Wed, 25 Mar 2026 11:51:46 +0000

Most deployment tutorials assume you are already on Linux or macOS. But if your daily machine runs Windows, you have likely hit the gap between it works on my laptop and it works on the server. WSL2 closes that gap — it gives you a real Linux kernel inside Windows, so your local Docker containers behave exactly like they will in production.

This guide covers the full workflow: setting up WSL2 and Docker on Windows, structuring a project for deployment, and using DeployHQ to ship changes from your Git repository to a remote Linux server — automatically.

flowchart LR
    Dev["Windows + WSL2"] -->|git push| Git["GitHub / GitLab"]
    Git -->|webhook| DHQ["DeployHQ"]
    DHQ -->|SSH + files| Prod["Linux VPS"]
    DHQ -->|SSH commands| Prod

Why WSL2 for deployment workflows

If you develop on Windows and deploy to Linux servers, you have probably run into at least one of these problems:

Path differences : Windows uses backslashes and drive letters (C:\Users\), Linux uses forward slashes (/home/). Build scripts and Docker volumes break when they cross this boundary.
Shell incompatibilities : Bash scripts that run perfectly on the server fail in PowerShell or CMD.
File permission mismatches : Linux file permissions (chmod, chown) do not exist on NTFS, causing issues with Docker volume mounts and deployment scripts.
Line ending conflicts : Windows uses \r\n, Linux uses \n. A single wrong line ending can break a shell script or a Dockerfile.

WSL2 solves all of these by running a real Linux distribution (not an emulation layer) inside a lightweight VM managed by Windows. Docker Desktop integrates with WSL2 directly, so containers run on a real Linux kernel — identical to your production server.

Step 1 — Install WSL2 and Ubuntu

Open PowerShell as Administrator and run:

wsl --install -d Ubuntu-24.04

This installs WSL2 (the default since Windows 10 version 2004) and Ubuntu 24.04 LTS. Restart your machine when prompted.

After reboot, Ubuntu will launch and ask you to create a Linux username and password. These are separate from your Windows credentials.

Verify the installation:

wsl --list --verbose

You should see Ubuntu-24.04 running on WSL version 2.

Already have WSL1? Upgrade with wsl --set-version Ubuntu-24.04 2. WSL1 does not support Docker.

Step 2 — Install Docker Desktop with the WSL2 backend

Download and install Docker Desktop for Windows. During setup, ensure Use WSL 2 based engine is checked (it is the default).

After installation, open Docker Desktop and go to Settings > Resources > WSL Integration. Enable integration with your Ubuntu-24.04 distribution.

Verify from your WSL2 terminal:

docker --version
docker compose version

Both commands should work without sudo. Docker Desktop handles the daemon — you do not need to install Docker Engine inside WSL2 separately.

Performance tip

Store your project files inside the WSL2 filesystem (~/projects/), not on the Windows mount (/mnt/c/). File operations on /mnt/c/ are significantly slower due to the cross-filesystem translation layer.

mkdir -p ~/projects
cd ~/projects

Step 3 — Set up Git and SSH keys

Your WSL2 environment has its own Git configuration and SSH keys, separate from Windows. Configure them inside WSL2:

git config --global user.name "Your Name"
git config --global user.email "your@email.com"

Generate an SSH key for connecting to both your Git provider and your deployment server:

ssh-keygen -t ed25519 -C "your@email.com"
cat ~/.ssh/id_ed25519.pub

Add this public key to:

Your GitHub or GitLab account
Your remote server's ~/.ssh/authorized_keys file

Step 4 — Create a sample Docker Compose project

Let's create a minimal project to demonstrate the full workflow. This example uses Nginx serving a static site, but the pattern works for any Docker-based application.

cd ~/projects
mkdir my-app && cd my-app
git init

Create docker-compose.yml:

services:
  web:
    image: nginx:alpine
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./public:/usr/share/nginx/html:ro
    restart: unless-stopped

Create a simple page:

mkdir public
echo '<h1>Deployed with DeployHQ from WSL2</h1>' > public/index.html

Create .gitignore:

.env

Test locally:

docker compose up -d
curl http://localhost:8080

You should see your HTML. Stop it with docker compose down.

Commit and push:

git add .
git commit -m "Initial project setup"
git remote add origin git@github.com:your-username/my-app.git
git push -u origin main

Step 5 — Set up DeployHQ

DeployHQ connects your Git repository to your server and deploys changes automatically — or on your approval. Here is how to wire it up:

Create a new project in DeployHQ and connect your Git repository. DeployHQ supports GitHub, GitLab, Bitbucket, and any self-hosted Git server.
Add your server as a deployment target. Choose SSH/SFTP and enter your server's IP, SSH user, and deployment path (e.g., /home/deploy/my-app).
Configure SSH commands to manage Docker containers on each deployment:

Timing	Command	Purpose
Before upload	`cd /home/deploy/my-app && docker compose down`	Stop running containers
After upload	`cd /home/deploy/my-app && docker compose up -d --remove-orphans`	Start updated containers

DeployHQ runs SSH commands from the user's $HOME by default, so the cd prefix is required. See the deployment command examples for more patterns.

Enable automatic deployments (optional): Under project settings, enable auto-deploy so every push to main triggers a deployment without manual approval.

Step 6 — Deploy and verify

From your WSL2 terminal, make a change and push:

echo '<h1>Updated from WSL2!</h1><p>Deployed automatically.</p>' > public/index.html
git add .
git commit -m "Update landing page"
git push

DeployHQ will:

Detect the new commit via webhook
Upload changed files to your server
Run the SSH commands to restart Docker containers

Check the deployment log in your DeployHQ dashboard to confirm success.

Step 7 — Edit with VS Code from Windows

One of the best parts of WSL2: you can edit files inside the Linux filesystem using VS Code on Windows. Install the WSL extension, then from your WSL2 terminal:

cd ~/projects/my-app
code .

VS Code opens on Windows but operates inside WSL2 — file access, terminal, Git, and Docker commands all run natively in Linux. Your workflow becomes:

Edit in VS Code on Windows
Test with docker compose up in the integrated WSL2 terminal
Commit and push from the same terminal
DeployHQ deploys to your Linux server automatically

No context switching. No path translation issues. No works on my machine surprises.

Going further: real-world project patterns

Environment-specific configuration

Use separate Compose files for local development and production:

# Local development (with hot reload, debug ports)
docker compose -f docker-compose.yml -f docker-compose.dev.yml up

# Production uses the base file only
# DeployHQ deploys docker-compose.yml to the server

Using DeployHQ build pipelines

If your project needs a build step (compiling assets, running tests), DeployHQ build pipelines can run commands before deploying. For example:

npm install && npm run build

This runs on DeployHQ's build servers, so your production server only receives the compiled output.

Docker image builds with DeployHQ

For projects that build custom Docker images, DeployHQ's Docker build feature can build and push images to Docker Hub, GitHub Container Registry, or other registries — then deploy a docker compose pull && docker compose up -d on your server.

Rolling back

If a deployment breaks something, open DeployHQ's deployment history and click Redeploy this version on the last working deployment. The SSH commands will restart the containers with the previous configuration.

Troubleshooting

Docker commands not available in WSL2 Open Docker Desktop > Settings > Resources > WSL Integration and ensure your Ubuntu distro is enabled. Then restart your WSL2 terminal.

Slow file access in Docker volumes You are likely mounting from /mnt/c/. Move your project to ~/projects/ inside WSL2. The performance difference is substantial.

SSH key not working with DeployHQ or your serverMake sure you generated the key inside WSL2 (not Windows). Check permissions: chmod 600 ~/.ssh/id_ed25519. Test with ssh -T git@github.com or ssh deploy@your-server-ip.

Line ending issues in Git Configure Git inside WSL2 to keep Linux line endings:

git config --global core.autocrlf input

This ensures files stay with \n endings even if you occasionally edit them from Windows.

DeployHQ deployment times out Docker image pulls can be slow on the first deployment. Increase the SSH command timeout in DeployHQ's server settings, or pre-pull images on the server with docker compose pull before the first deploy.

Frequently asked questions

Can I use WSL2 without Docker Desktop?

Yes. You can install Docker Engine directly inside your WSL2 Ubuntu distribution using the official Linux install steps. This avoids Docker Desktop entirely and is free for all team sizes. The trade-off is that you lose the GUI, automatic updates, and the seamless cross-distro integration that Docker Desktop provides. The deployment workflow with DeployHQ works exactly the same either way — it only cares about what you push to Git.

Does DeployHQ run on Windows or inside WSL2?

Neither. DeployHQ is a hosted service — it runs in the cloud. You interact with it through your browser or via Git webhooks. Your local environment (Windows, WSL2, macOS, Linux) only matters for writing code and pushing commits. DeployHQ connects to your Git provider and your remote server independently.

Is WSL2 fast enough for Docker development?

For containers and builds, WSL2 performs at near-native Linux speed. The one bottleneck is cross-filesystem access — reading files from /mnt/c/ (the Windows drive) inside a container is significantly slower than reading from the native Linux filesystem (~/). Keep your projects inside WSL2's home directory and performance will not be an issue.

Can I deploy to multiple servers from the same project?

Yes. DeployHQ supports multiple servers per project. You can deploy the same Git repository to a staging server and a production server with different SSH commands for each. For example, staging could auto-deploy on every push, while production requires manual approval.

What if my team uses a mix of Windows, macOS, and Linux?

That is one of the main advantages of this workflow. Docker Compose files are cross-platform, Git is cross-platform, and DeployHQ does not care what OS pushed the commit. Team members on macOS or Linux skip the WSL2 step and use Docker natively — the rest of the workflow (Git push → DeployHQ → server) is identical.

Do I need WSL2 if I only deploy static sites or PHP apps (no Docker)?

No. WSL2 and Docker are optional. DeployHQ can deploy any Git repository to any server over SSH/SFTP — no containers needed. WSL2 becomes valuable when your production stack uses Docker, because it lets you run the same containers locally on Windows that you will run on the server. For static sites or traditional PHP deployments, DeployHQ works directly without any local Docker setup.

Ready to bridge your Windows development environment with production Linux servers? Sign up for DeployHQ and connect your first project in minutes.

For questions or help, reach out to support@deployhq.com or find us on X (@deployhq).

Heroku Enters Sustaining Engineering Mode: What It Means and When to Consider Alternatives

DeployHQ — Mon, 23 Mar 2026 05:24:10 +0000

In February 2026, Salesforce announced that Heroku is transitioning to a sustaining engineering model. No new features, no new Enterprise contracts for new customers, and a strategic pivot toward AI-driven products instead of platform development.

For the thousands of teams that built their deployment workflows around Heroku, this raises a practical question: what now?

This article breaks down what the announcement actually means, who should consider migrating, and how DeployHQ fits as a deployment layer — especially if you deploy to your own servers or cloud infrastructure.

What Heroku's Sustaining Engineering Actually Means

Heroku's official update and March 2026 follow-up confirm the following:

No new feature development. The roadmap is defensive — security patches, stability fixes, and infrastructure maintenance only.
Enterprise contracts are no longer offered to new customers. Existing Enterprise customers can renew, but Salesforce is not onboarding new ones.
Credit card customers are unaffected for now. If you pay via the Heroku dashboard, pricing and billing remain the same.
No sunset date announced. Heroku could run in this mode for years, but long-term certainty decreases over time.

The March 2026 update framed this as a mission to provide the most stable, secure, and reliable environment for your apps and data — but conspicuously dropped any mention of innovation or feature roadmap.

In software terms, sustaining engineering is the phase before end-of-life. It does not mean Heroku is shutting down tomorrow. It means the platform has stopped evolving, and teams planning for the next 2-5 years should factor that into their infrastructure decisions.

Who Should Consider Moving — And Who Shouldn't

Not every Heroku customer needs to migrate immediately. Here is a practical framework:

Stay on Heroku (for now) if:

Your app is stable, low-traffic, and doesn't require new platform features
You are on a credit card plan with no Enterprise dependencies
You have no compliance requirements that demand an active development roadmap from your platform vendor
Migration cost exceeds the risk of remaining on a sustaining platform

Start planning a migration if:

You need features Heroku will never ship (private networking, advanced build controls, regional deployment)
You are an Enterprise customer whose contract renewal terms may change
Your compliance or security team requires vendors with active development commitments
You are scaling and hitting Heroku's known limitations (30-second request timeout, daily dyno restarts, limited build customisation)
You deploy to your own servers, VPS, or cloud infrastructure — Heroku was always an awkward fit for this

Why DeployHQ Is Worth Considering

DeployHQ is not a Heroku replacement in the traditional PaaS sense. It does not host your application or manage your infrastructure. Instead, it handles one thing exceptionally well: getting your code from a Git repository to your servers, reliably and automatically.

This distinction matters. Many Heroku users — particularly those deploying PHP, Ruby, Python, or Node.js applications — do not actually need a full PaaS. They need a deployment pipeline that connects to their existing servers.

Here is where DeployHQ fits:

Git-Native Deployment

DeployHQ connects directly to GitHub, GitLab, and Bitbucket. Push to a branch and your code is deployed — similar to Heroku's git push heroku main workflow, but to any server you control.

Zero Downtime Deployments

Heroku handles this behind the scenes with its dyno management. With DeployHQ, zero downtime deployments work by maintaining atomic release directories on your server. New releases are prepared in isolation, symlinked on success, and rolled back instantly on failure.

One-Click Rollback

One of Heroku's best features was easy rollbacks. DeployHQ provides one-click rollback to any previous deployment — no CLI commands, no release slugs to manage.

Build Pipelines

If your application needs a build step (compiling assets, installing dependencies, running tests), DeployHQ's build pipelines run these steps before deployment. Similar to Heroku's buildpacks, but configurable to match your exact workflow.

Deploy Behind Firewalls

Unlike Heroku, which is limited to its own infrastructure, DeployHQ can deploy behind firewalls using network agents — reaching servers in private networks, corporate environments, or air-gapped infrastructure.

Docker Builds

For teams moving toward containers, DeployHQ supports Docker builds as part of the deployment pipeline — build, test, and deploy container images to any registry or server.

Migration Checklist: Heroku to DeployHQ

If you decide to move, here is a practical migration path:

1. Audit Your Heroku Setup

Before changing anything, document what you have:

Application type : Web app, API, worker process, or scheduled job?
Language/framework : PHP, Ruby, Python, Node.js, Go?
Add-ons : Which Heroku add-ons do you depend on? (Postgres, Redis, logging, monitoring)
Environment variables : Export your config vars (heroku config -s > .env)
Build process : What does your Procfile and buildpack do?

2. Provision Your Server

DeployHQ deploys to servers you control. You will need:

A VPS or cloud server (DigitalOcean, AWS EC2, Linode, Hetzner, or your own hardware)
SSH access configured
Your runtime environment installed (PHP, Node.js, Ruby, Python)

For teams deploying WordPress, Laravel, Rails, Django, or Express apps to a VPS, this is a natural fit. DeployHQ's deployment targets support SSH/SFTP, Amazon S3, Rackspace Cloud Files, and more.

3. Set Up DeployHQ

Sign up for DeployHQ
Create a project and connect your Git repository
Configure your server as a deployment target
Set up environment-specific config files to replace Heroku's config vars
Add build pipeline steps if needed (e.g., npm install && npm run build)
Configure automatic deployments to trigger on push

4. Migrate Your Data

PostgreSQL : Export with pg_dump, import to your new database server
Redis : Export with redis-cli --rdb or use BGSAVE
File storage : If you used ephemeral storage on Heroku, move to S3 or equivalent

5. Update DNS and Go Live

Point your domain to your new server, run smoke tests, and monitor with your preferred observability stack. DeployHQ integrates with Slack, Discord, and other notification services to keep your team informed during the transition.

DeployHQ vs Heroku: A Practical Comparison

Capability	Heroku	DeployHQ
What it does	Hosts and runs your app (PaaS)	Deploys code to your servers
Server management	Fully managed	You manage your servers
Git push deploys	Yes	Yes
Rollback	Via CLI (`heroku rollback`)	One-click in dashboard
Build steps	Buildpacks (limited customisation)	Fully configurable build pipelines
Zero downtime	Preboot (paid plans)	Included on all plans
Deploy to own servers	No	Yes (SSH, SFTP, S3, and more)
Private network support	No	Yes (via network agents)
Docker support	Container registry	Docker build pipelines
Integrations	Heroku add-ons marketplace	GitHub, GitLab, Bitbucket, Slack, Sentry, and more
Pricing	Starts at $5/mo per dyno	Starts at $4/mo for 10 projects
Active development	Sustaining engineering only	Active feature development

What DeployHQ Does Not Replace

To be transparent: DeployHQ is not a drop-in Heroku replacement for every use case.

App hosting : DeployHQ does not run your application. You need your own server or hosting provider.
Managed databases : Heroku Postgres was convenient. You will need to self-manage or use a managed database service (AWS RDS, DigitalOcean Managed Databases, PlanetScale, Neon).
Add-on marketplace : Heroku's add-on ecosystem has no direct equivalent. You will integrate services directly.
Scaling : Heroku's dyno scaling is automatic. With your own servers, you handle scaling yourself (or use auto-scaling from your cloud provider).

For teams that want the full PaaS experience, platforms like Render, Railway, or Fly.io are closer Heroku replacements. DeployHQ targets a different — and arguably larger — audience: developers who already have servers and need a reliable way to deploy to them.

The Bigger Picture

Heroku's move to sustaining engineering is part of a broader industry trend. Salesforce acquired Heroku in 2010 for $212 million, and the platform defined a generation of developer experience. But priorities shift, and Salesforce's investment is now directed toward enterprise AI.

For developers, the lesson is practical: avoid single points of failure in your deployment infrastructure. Whether you stay on Heroku for now or migrate to a combination of your own servers and a deployment tool like DeployHQ, the goal is the same — control over how and where your code runs.

Ready to take control of your deployments? Start a free trial of DeployHQ and deploy your first project in under 5 minutes. If you have questions about migrating from Heroku, reach out to us at support@deployhq.com or on Twitter at @deployhq.

Introducing the DeployHQ Chrome Extension: Deploy Without Leaving Your Browser

DeployHQ — Wed, 18 Mar 2026 07:43:07 +0000

If you deploy web applications, you know the routine: switch to your deployment platform, find the right project, pick the branch, and hit deploy. It works, but it pulls you out of your flow every single time.

The DeployHQ Chrome Extension eliminates that context switch entirely. It brings deployment controls directly into GitHub, GitLab, and Bitbucket — the platforms where you already review and merge code.

What Does the Chrome Extension Do?

The extension adds a Deploy with DeployHQ button to your repository pages on GitHub, GitLab, and Bitbucket. Instead of navigating to a separate deployment dashboard, you trigger deployments from the same page where you just merged a pull request or pushed a commit.

Here's what it covers:

One-click deploys from repository root pages, branch pages, and pull/merge request pages
Project dashboard with a searchable list of your DeployHQ projects and their latest deployment timestamps
Server and branch selection so you can target specific environments before deploying
Real-time notifications via desktop alerts when deployments start, succeed, or fail
Badge indicators on the extension icon — blue for active deployments, red for failures

If a repository isn't connected to DeployHQ yet, the extension shows a Connect to DeployHQ link instead, making it easy to set up new projects without leaving your browser.

Why This Matters for Your Workflow

Most deployment friction isn't about the deploy itself — it's about the interruption. You finish a code review, approve the PR, merge it, and then... open a new tab, log in to your deployment tool, navigate to the right project, and trigger the deploy manually.

With the Chrome Extension, the deploy button is right there on the pull request page. Merge and deploy in one smooth motion.

This is especially useful if you practice continuous delivery — where every merged change should reach staging or production quickly. The fewer steps between merge and deploy, the faster your feedback loop.

Getting Started

Installation

Visit the Chrome Web Store listing and click Add to Chrome
Confirm the installation when prompted

The extension needs permissions for:

Storage — to save your credentials locally
Notifications — to alert you about deployment status
Site access — to deployhq.com, github.com, gitlab.com, and bitbucket.org

Configuration

Click the extension icon in your browser toolbar and enter:

Your DeployHQ subdomain (e.g., mycompany if your account is at mycompany.deployhq.com)
Your email address associated with the account
Your API key — find this in your DeployHQ account under Settings > Security

Your credentials are stored locally in your browser and are never sent to any third party.

Customisation

The extension offers a few configurable options:

Polling interval — how often it checks for deployment updates (default: 60 seconds)
Notifications — toggle desktop alerts on or off
Platform integrations — enable or disable the deploy button on GitHub, GitLab, or Bitbucket individually

How It Fits with the Rest of DeployHQ

The Chrome Extension is one of several ways to interact with DeployHQ beyond the web dashboard:

API — full programmatic access for custom integrations and automation scripts
CLI Tool — trigger and manage deployments from your terminal
MCP Server — integrate DeployHQ with AI coding assistants like Claude Code
Integrations — connect with Slack, Discord, Sentry, and other tools in your stack

Whether you prefer a browser-based workflow, a terminal-first approach, or AI-assisted automation, DeployHQ meets you where you work.

Open Source

The Chrome Extension is fully open source. You can browse the code, report issues, or contribute improvements on the GitHub repository.

If you spot a bug or have a feature request, opening an issue there is the fastest way to get it addressed.

What's Next

If you're already using DeployHQ, install the extension and shave a few seconds off every deployment. Those seconds add up — especially on teams that deploy multiple times a day.

If you haven't tried DeployHQ yet, sign up for a free account and experience how simple deployment can be — from GitHub, GitLab, or any Git repository.

Have questions or feedback? Reach out to support@deployhq.com or find us on X/Twitter.

Continuous Delivery vs Continuous Deployment: What's the Difference?

DeployHQ — Fri, 13 Mar 2026 11:39:07 +0000

Continuous delivery and continuous deployment sound almost identical, and most teams use the terms interchangeably. That confusion is costly. The difference between them determines who (or what) decides when your code reaches production, and getting that decision wrong can mean either unnecessary bottlenecks or uncontrolled releases hitting your users.

Quick definitions

Continuous delivery means every code change is built, tested, and packaged into a release artifact that could go to production at any moment. The pipeline does everything except the final step: a human decides when to press the deploy button. Your code is always in a deployable state, but deployment remains a deliberate business decision.

Continuous deployment takes that one step further. Every change that passes the full automated test suite is deployed to production automatically, with no human gate. There is no deploy button. If the tests pass, your users see the change within minutes.

The distinction comes down to a single question: is there a human approval step before production, or not?

flowchart LR
    A[Code Commit] --> B[Build & Unit Tests]
    B --> C[Integration Tests]
    C --> D[Staging Deploy]
    D --> E{Human Approval?}
    E -- "Yes: Continuous Delivery" --> F[Manual Production Deploy]
    E -- "No: Continuous Deployment" --> G[Automatic Production Deploy]

How they relate to continuous integration

Neither continuous delivery nor continuous deployment works without continuous integration (CI) as the foundation. CI is the practice of merging code changes frequently and running automated builds and tests on every merge. It catches integration issues early and keeps the main branch in a working state.

Think of it as a spectrum:

Continuous integration --- automated build and test on every commit
Continuous delivery --- CI + automated release pipeline + manual deploy gate
Continuous deployment --- CI + automated release pipeline + automatic deploy

Each level builds on the previous one. You cannot skip straight to continuous deployment without first having solid CI and a reliable delivery pipeline. For a deeper look at how these pieces fit together, see What is CI/CD?.

flowchart TD
    CI["Continuous Integration<br/>Build + Test on every commit"] --> CD_DELIVERY["Continuous Delivery<br/>+ Release pipeline<br/>+ Manual deploy gate"]
    CD_DELIVERY --> CD_DEPLOY["Continuous Deployment<br/>+ Automatic production deploy"]

    style CI fill:#e8f4f8,stroke:#2196F3
    style CD_DELIVERY fill:#fff3e0,stroke:#FF9800
    style CD_DEPLOY fill:#e8f5e9,stroke:#4CAF50

Key differences at a glance

Aspect	Continuous Delivery	Continuous Deployment
Deployment trigger	Manual approval	Automatic on passing tests
Risk tolerance	Lower --- human checkpoint catches edge cases	Higher --- trusts the automated test suite completely
Release cadence	On-demand, when the business decides	Every passing change, potentially dozens per day
Test requirements	High	Very high --- tests are the only gate to production
Rollback strategy	Pre-deployment review catches most issues	Must have automated rollback and monitoring
Best for	Regulated industries, complex coordinated releases	SaaS products, web apps, fast-iteration teams
Team maturity needed	Moderate --- need solid CI and release pipeline	High --- need comprehensive tests, monitoring, and incident response

The practical effect: with continuous delivery, a deploy to production is a one-click action that happens when someone decides the time is right. With continuous deployment, there is no deploy action at all --- production updates are a side effect of merging code.

When continuous delivery is the right choice

Continuous delivery is not the lesser option. For many teams, it is the correct and deliberate choice.

Regulated industries demand it. If you are shipping software for healthcare, financial services, or government systems, compliance frameworks often require documented human approval before production changes. A payment processor cannot auto-deploy changes to transaction-handling code without a sign-off. Continuous delivery gives you the speed of an automated pipeline while preserving the audit trail regulators expect.

Coordinated releases need it. When a release involves database migrations, API version bumps, third-party integrations, or marketing launches, you need to control timing. Continuous delivery lets the pipeline prepare everything, then a team lead triggers the deploy when all the pieces are aligned.

Incomplete test coverage warrants it. If your automated test suite does not cover critical edge cases --- and honestly, most test suites have gaps --- a human review step before production is a reasonable safety net. The goal is to close those gaps over time, but in the meantime, delivery gives you a responsible middle ground.

Business timing matters. Sometimes you do not want changes going live on a Friday afternoon, during a peak traffic window, or before a coordinated announcement. Continuous delivery decouples ready to ship from shipped.

Example: fintech startup

A payments team has 40 microservices. Their core transaction services use continuous delivery: every merge to main triggers the full pipeline and deploys to staging automatically, but production deploys require a senior engineer to approve in the deployment dashboard. Their internal tooling services, which are lower risk, use continuous deployment. This mixed approach balances speed with the compliance requirements their banking partners enforce.

When continuous deployment makes sense

Continuous deployment is not reckless --- it is a sign that your engineering practices have matured to the point where you trust your automated systems more than manual review.

SaaS products thrive on it. When your product is a web application with thousands of users, shipping small changes frequently reduces the blast radius of any single deploy. A five-line CSS fix and a critical security patch go through the same pipeline. Both are live within minutes of merging.

Comprehensive test suites enable it. If your team has invested in unit tests, integration tests, end-to-end tests, contract tests, and performance benchmarks that collectively cover the critical paths, those tests are a more reliable gate than a tired engineer reviewing a pull request at 4pm. Continuous deployment works when you trust the tests.

Feature flags provide a safety net. Continuous deployment does not mean every user sees every change immediately. Teams using feature flags can deploy code to production without activating it, then gradually roll out to a percentage of users. If something breaks, disable the flag --- no rollback needed.

Microservices architectures benefit. When services are independently deployable, continuous deployment per service is natural. Each team owns their deploy pipeline and cadence. A change to the notification service does not need to coordinate with the billing service.

Example: SaaS startup

A 15-person engineering team runs a project management SaaS. They merge to main 20-30 times per day. Every merge triggers the pipeline: build, 2,000+ automated tests, deploy to canary, monitor error rates for 5 minutes, then promote to full production. Average time from merge to live: 12 minutes. They find and fix issues faster than teams that batch releases weekly because each deploy is small and easy to reason about.

The hybrid approach most teams actually use

In practice, very few organisations pick one approach exclusively. The most effective teams use different strategies for different contexts.

Continuous deployment to staging, continuous delivery to production. Every merge auto-deploys to a staging environment where QA, product managers, and stakeholders can review. Production deploys happen when the team is ready. This is the most common pattern for teams transitioning from manual deployments.

Different pipelines for different risk levels. Frontend changes to marketing pages might auto-deploy. Backend changes to authentication or billing go through a manual approval gate. The risk profile of the change determines the process, not a blanket policy.

Feature flags bridge the gap. With feature flags, you can have continuous deployment (code goes to production automatically) while maintaining continuous delivery semantics (the feature is not released until someone enables the flag). This gives you the deployment speed of CD with the release control of delivery.

Understanding what software deployment actually involves helps you design these pipelines with the right level of automation for each stage.

Common misconceptions

Continuous deployment means no testing. This is backwards. Continuous deployment requires more testing than continuous delivery, not less. When tests are the only gate to production, they must be comprehensive, fast, and reliable. Teams doing continuous deployment typically invest heavily in test infrastructure.

Continuous delivery is just manual deployment. No. With continuous delivery, the entire pipeline is automated --- build, test, package, deploy to staging, run acceptance tests. The only manual step is the final approval to promote to production. That approval might be a single click in a dashboard, not a manual deployment process.

You need continuous deployment to move fast. Not necessarily. A team doing continuous delivery with a one-click deploy can ship a hotfix to production in under 5 minutes. The difference between auto-deploy on merge and click a button after merge is seconds, not hours. The real speed gains come from CI and automated pipelines, which both approaches share.

Continuous deployment is always the goal. It depends entirely on your context. A hospital's medical device software should not auto-deploy to production. A personal blog's deployment pipeline probably should. The best approach is the one that matches your risk tolerance, regulatory requirements, and team capabilities.

You have to choose one. As covered in the hybrid section, most teams use both. The question is not which one? but which one for this particular service or change?

How \DeployHQ supports both approaches

Whether your team practises continuous delivery, continuous deployment, or a hybrid of both, DeployHQ handles the deployment step.

For continuous delivery workflows , DeployHQ deploys automatically when you push to a branch, but you control which branch triggers a deploy and when you merge to it. Your deployment dashboard shows pending deployments, lets you review what will change, and gives you a one-click deploy when you are ready. You stay in control of timing.

For continuous deployment workflows , configure DeployHQ to deploy on every push to your main branch. Pair this with your CI server --- when your tests pass and code merges, DeployHQ picks up the change and deploys it automatically. Your CI pipeline is the gate; DeployHQ is the delivery mechanism.

Zero-downtime deployments are essential for continuous deployment. DeployHQ supports atomic deployments that swap the live version only after the new version is fully uploaded, so your users never see a half-deployed state.

Build pipelines let you run build commands (npm install, webpack, composer install) on \DeployHQ's servers before deploying. This means your CI server handles testing while DeployHQ handles building and deploying --- a clean separation of concerns.

One-click rollback provides a safety net for both approaches. If a deploy introduces a problem, roll back to the previous version in seconds from the DeployHQ dashboard.

For teams deploying from GitHub, setting up automatic deployments takes minutes. Push to main, DeployHQ deploys. Push to staging, DeployHQ deploys to your staging server. Different branches, different servers, different strategies.

Getting started: a practical path

If you are not doing either yet , start with continuous integration. Get automated builds and tests running on every commit. Once your team trusts the CI pipeline, add automated staging deploys --- that is continuous delivery. For a step-by-step guide, see CI/CD Pipelines: The Complete Guide.

If you are doing continuous delivery , evaluate whether your test suite is comprehensive enough to remove the manual gate. Track how often the human approval step actually catches issues that tests missed. If the answer is rarely, you might be ready for continuous deployment --- at least for lower-risk services.

If you are doing continuous deployment , make sure your safety nets are solid. Automated rollback should be fast (under 60 seconds). Monitoring should alert on error rate spikes within minutes. Incident response should be practised, not theoretical. And review whether continuous deployment as a practice is working for every service, or if some should move back to delivery.

The maturity path looks like this:

flowchart TD
    A["Manual Deployments<br/>FTP uploads, SSH scripts"] --> B["Continuous Integration<br/>Automated build + test"]
    B --> C["Continuous Delivery<br/>Automated pipeline + manual gate"]
    C --> D["Continuous Deployment<br/>Fully automated to production"]
    C --> E["Hybrid Approach<br/>CD for low-risk, Delivery for high-risk"]
    D --> E

    style A fill:#ffebee,stroke:#f44336
    style B fill:#e8f4f8,stroke:#2196F3
    style C fill:#fff3e0,stroke:#FF9800
    style D fill:#e8f5e9,stroke:#4CAF50
    style E fill:#f3e5f5,stroke:#9C27B0

Most teams land on the hybrid approach, and that is perfectly fine. The goal is not to reach the end of the spectrum --- it is to find the deployment strategy that lets your team ship confidently and frequently.

Ready to automate your deployments? Sign up for \DeployHQ and set up your first deployment pipeline in minutes, whether you are practising continuous delivery, continuous deployment, or both.

If you have questions about setting up your deployment workflow, reach out at support@deployhq.com or find us on Twitter/X @deployhq.

CI/CD Pipelines: The Complete Guide

DeployHQ — Fri, 13 Mar 2026 11:39:02 +0000

If you already know what CI/CD is, the next question is practical: how do you actually build a pipeline that works for your team? This guide walks through designing, configuring, securing, and optimizing a CI/CD pipeline from scratch. No enterprise-scale assumptions — just actionable steps you can implement today.

Anatomy of a CI/CD Pipeline

Every CI/CD pipeline follows the same fundamental flow, regardless of the tools you use. Code moves through a series of automated stages, each acting as a quality gate before the next.

flowchart LR
    A[Source] --> B[Build]
    B --> C[Test]
    C --> D[Deploy]
    D --> E[Monitor]
    E -->|Rollback| D

Source is where everything starts. A commit or pull request triggers the pipeline. Your CI system detects the change, checks out the code, and begins processing.

Build compiles your application, installs dependencies, and produces deployable artifacts. For interpreted languages like Python or PHP, this might just be dependency installation and asset compilation. For compiled languages like Go or Java, it includes the actual compilation step. For a deeper look at what a build pipeline is and how to structure one, start there. The build pipelines feature in DeployHQ lets you run build commands as part of the deployment process.

Test runs your automated test suite against the built artifacts. This is the most critical gate — if tests fail, the pipeline stops and nothing reaches production.

Deploy pushes the tested artifacts to your target environment. This could be a staging server for manual review or production for fully automated continuous deployment. DeployHQ handles this stage with support for automatic deployments triggered by webhooks or API calls.

Monitor watches the deployed application for errors, performance degradation, or unexpected behavior. Good monitoring closes the feedback loop — if something breaks, you catch it before your users do.

Designing Your Pipeline

Before writing any configuration, make three decisions that shape everything else.

Branch Strategy

Trunk-based development works best for small-to-medium teams. Everyone commits to main (or short-lived feature branches that merge within a day or two). The pipeline runs on every push to main, and deployments happen frequently.

GitFlow uses long-lived develop, release, and hotfix branches. It adds ceremony but gives you more control over what reaches production and when. If your release cycle is weekly or longer, GitFlow might make sense.

For most teams, trunk-based development with feature flags is the simpler, faster option. You deploy more often, which means smaller changes, which means fewer things break.

Environment Strategy

A typical setup uses three environments:

Environment	Purpose	Deploys from	Audience
Development	Integration testing	Feature branches	Developers
Staging	Pre-production validation	`main` branch	QA, stakeholders
Production	Live application	Tagged releases or `main`	Users

You can start with just staging and production. Add environments only when you have a concrete reason — each one adds maintenance overhead and slows your feedback loop.

Delivery vs. Deployment

Continuous delivery means every commit that passes the pipeline is ready to deploy, but a human clicks the button. Continuous deployment means every passing commit goes to production automatically, with no manual gate. The comparison between these approaches is worth reading if you are deciding which to adopt.

Start with continuous delivery. Move to continuous deployment once your test suite is comprehensive enough that you trust it to catch regressions without human review.

Pipeline Configuration Example

Here is a real GitHub Actions workflow that builds a Node.js application, runs tests in parallel, and triggers a DeployHQ deployment on success.

name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'

      - run: npm ci

      - run: npm run build

      - uses: actions/upload-artifact@v4
        with:
          name: build-output
          path: dist/
          retention-days: 1

  test-unit:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'

      - run: npm ci

      - run: npm run test:unit -- --shard=${{ matrix.shard }}
    strategy:
      matrix:
        shard: [1/3, 2/3, 3/3]

  test-integration:
    needs: build
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_DB: test
          POSTGRES_PASSWORD: test
        ports:
          - 5432:5432
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'

      - run: npm ci

      - run: npm run test:integration
        env:
          DATABASE_URL: postgres://postgres:test@localhost:5432/test

  deploy:
    needs: [test-unit, test-integration]
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    runs-on: ubuntu-latest
    steps:
      - name: Trigger DeployHQ deployment
        run: |
          curl -s -X POST \
            "${{ secrets.DEPLOYHQ_WEBHOOK_URL }}" \
            -H "Content-Type: application/json" \
            -d '{"branch": "main"}'

A few things to notice in this configuration:

Dependency caching (cache: 'npm') avoids re-downloading packages on every run. This alone can cut 30-60 seconds off each build.
Test sharding splits unit tests across three parallel runners. A test suite that takes 6 minutes sequentially finishes in roughly 2 minutes.
DeployHQ as the CD step keeps your deployment logic out of CI. The webhook triggers DeployHQ, which handles the actual file transfer, build commands, and server configuration. This separation means you can change your CI provider without touching your deployment setup.

If you are deploying from GitHub, DeployHQ can also detect pushes directly without the webhook — but using a webhook gives you the option to deploy only after CI passes.

Testing in Your Pipeline

Not all tests belong in every pipeline run. The testing pyramid helps you decide what to run and when.

flowchart TB
    subgraph Pyramid["Testing Pyramid"]
        direction TB
        E2E["E2E Tests\n(few, slow, high confidence)"]
        INT["Integration Tests\n(moderate count, moderate speed)"]
        UNIT["Unit Tests\n(many, fast, focused)"]
    end
    E2E --- INT
    INT --- UNIT

Unit tests run on every commit. They are fast (seconds to low minutes), test individual functions in isolation, and catch logic errors early. If your unit tests take longer than 3 minutes, split them into parallel shards.

Integration tests run on every push to main and on pull requests. They verify that components work together — database queries return expected results, API endpoints respond correctly, services communicate as expected.

End-to-end tests run before production deployments, ideally on a staging environment. They simulate real user workflows through a browser. E2E tests are slow and brittle, so keep the count low — cover critical paths (signup, checkout, core features) and nothing more.

The key principle: fast feedback first. A developer should know within 2-3 minutes whether their change broke something. Push expensive tests later in the pipeline where they do not block the inner development loop.

Deployment Strategies

How code reaches production matters as much as how it is tested. The right strategy depends on your risk tolerance, infrastructure, and team size. For a broader look at what software deployment involves, start there.

Direct Deployment

The simplest approach: upload new files and replace the old ones. This works for static sites and small applications where a few seconds of downtime during the swap is acceptable.

Zero-Downtime Deployment

Uses symlink switching to swap between releases atomically. The new version is uploaded to a fresh directory, and once ready, the web server's document root symlink is flipped to point at it. There is no moment where the application is unavailable. DeployHQ supports this natively — see zero-downtime deployments with DeployHQ for the setup walkthrough.

Blue-Green Deployment

Maintains two identical production environments. Traffic routes to blue while green receives the new deployment. After validation, traffic switches from blue to green.

flowchart LR
    LB[Load Balancer]
    LB -->|Active| Blue[Blue Environment\nv1.2.3]
    LB -.->|Standby| Green[Green Environment\nv1.2.4]
    Green -->|Validated| Switch{Switch Traffic}
    Switch -->|Cutover| LB

The advantage is instant rollback — just switch traffic back to blue. The downside is cost: you are running two full environments.

Canary Deployment

Routes a small percentage of traffic (typically 5-10%) to the new version while the rest continues hitting the current version. If error rates stay flat, you gradually increase the percentage until 100% of traffic reaches the new version.

Canary deployments catch issues that only surface under real traffic patterns — race conditions, performance regressions at scale, edge cases your test suite missed. They require a load balancer that supports weighted routing.

Rolling Deployment

Updates servers one at a time (or in small batches) behind a load balancer. At any point during the rollout, some servers run the old version and some run the new. This works well for stateless applications but can cause issues if the old and new versions are not compatible with each other (different database schemas, changed API contracts).

For most small-to-medium teams, zero-downtime deployment via symlink switching hits the sweet spot — no downtime, simple rollback, and no extra infrastructure cost.

Security in CI/CD Pipelines

Your pipeline has access to production credentials, source code, and deployment infrastructure. Treat it as a high-value attack surface.

Secrets Management

Never hardcode secrets in pipeline configuration files or repository code. Use your CI provider's encrypted secrets store (GitHub Actions Secrets, GitLab CI Variables, etc.) and inject them as environment variables at runtime.

# Good: secrets injected at runtime
env:
  DATABASE_URL: ${{ secrets.DATABASE_URL }}
  API_KEY: ${{ secrets.API_KEY }}

# Bad: secrets in the repository (never do this)
env:
  DATABASE_URL: "postgres://admin:password123@db.example.com/prod"

Rotate secrets on a schedule. If a secret is ever exposed in logs or a commit, rotate it immediately.

Dependency Scanning

Automated tools like npm audit, Dependabot, or Snyk scan your dependency tree for known vulnerabilities. Run these on every pull request — they add seconds to the pipeline and catch issues before they merge.

- name: Audit dependencies
  run: npm audit --audit-level=high

Static Analysis (SAST)

Static Application Security Testing scans your source code for common vulnerabilities: SQL injection, XSS, insecure deserialization, hardcoded credentials. Tools like Semgrep, SonarQube, or CodeQL integrate directly into CI workflows.

Supply Chain Security

Lock files (package-lock.json, Gemfile.lock, poetry.lock) pin exact dependency versions. Always commit them and use deterministic install commands (npm ci instead of npm install) to prevent supply chain attacks where a compromised package publishes a malicious minor version.

Deployment Permissions

Use role-based access control (RBAC) for deployment. Not everyone who can merge code should be able to deploy to production. DeployHQ supports team permissions that let you restrict who can trigger deployments to specific environments.

Monitoring and Rollback

Deploying is only half the job. You need to know whether the deployment actually worked.

Post-Deployment Health Checks

After every deployment, run automated checks:

HTTP health endpoint returns 200 with expected response body
Database connectivity confirmed via a lightweight query
External service dependencies are reachable
Key business metrics (error rate, response time) remain within normal bounds

If any check fails within the first 5 minutes, trigger a rollback automatically.

Automated Rollback

Define clear rollback triggers:

Signal	Threshold	Action
HTTP 5xx error rate	>5% for 2 minutes	Auto-rollback
Response time p95	>2x baseline for 5 minutes	Alert + manual rollback
Health check failure	Any check fails	Auto-rollback
Critical exception spike	>10x normal rate	Auto-rollback

DeployHQ provides one-click rollback to any previous deployment, which makes recovery a matter of seconds rather than minutes. For a deeper look at how deployment automation reduces recovery time, that guide covers the specifics.

Error Monitoring

Integrate error tracking (Sentry, Bugsnag, Honeybadger) into your application. These tools catch unhandled exceptions, group them by root cause, and alert your team. The deployment marker feature in most error trackers lets you correlate error spikes with specific deployments.

Pipeline Performance Optimization

A slow pipeline kills developer productivity. If your pipeline takes 20 minutes, developers context-switch while waiting, and feedback arrives too late to be useful. Target under 10 minutes for the full pipeline — under 5 minutes is excellent.

Cache Dependencies

Every major CI platform supports dependency caching. Use it.

Language	Cache target	Typical savings
Node.js	`~/.npm` or `node_modules`	30-90 seconds
Python	`~/.cache/pip`	20-60 seconds
Ruby	`vendor/bundle`	30-90 seconds
Go	`~/go/pkg/mod`	15-45 seconds

Parallelize Test Suites

Split tests across multiple runners. GitHub Actions supports matrix strategies that shard your test suite automatically. Three shards typically give you a 2.5-3x speedup for minimal additional cost.

Incremental Builds

Only rebuild what changed. Monorepo tools like Nx and Turborepo track file dependencies and skip unchanged packages. For simpler projects, check whether source files changed before running expensive steps:

- name: Check if build needed
  id: changes
  run: |
    if git diff --name-only HEAD~1 | grep -q '^src/'; then
      echo "build_needed=true" >> $GITHUB_OUTPUT
    fi

- name: Build
  if: steps.changes.outputs.build_needed == 'true'
  run: npm run build

Artifact Reuse

Build once, deploy the same artifact everywhere. Upload build artifacts in the build job and download them in subsequent jobs instead of rebuilding. This ensures what you tested is exactly what you deploy — no it worked on CI surprises.

Measuring Pipeline Effectiveness

The DORA (DevOps Research and Assessment) metrics are the industry standard for measuring how well your delivery process performs. Track these four metrics to know whether your pipeline is actually helping.

Metric	Elite	High	Medium	Low
Deployment frequency	On-demand (multiple/day)	Weekly to monthly	Monthly to 6-monthly	Fewer than once per 6 months
Lead time for changes	Less than 1 hour	1 day to 1 week	1 week to 1 month	More than 1 month
Mean time to recovery	Less than 1 hour	Less than 1 day	1 day to 1 week	More than 1 week
Change failure rate	0-15%	16-30%	31-45%	46-60%

Source: DORA State of DevOps Report

You do not need to be elite across all four metrics. Focus on the ones that hurt most. If your change failure rate is high, invest in testing. If your lead time is long, look for pipeline bottlenecks and manual approval gates that could be automated.

The relationship between these metrics matters too. Deploying more frequently reduces change failure rate because each deployment is smaller and easier to reason about. Faster mean time to recovery comes from having reliable rollback and good monitoring — not from deploying less often.

CI/CD for Small Teams

Most CI/CD content assumes you have a dedicated platform team, a Kubernetes cluster, and a budget for enterprise tools. If that is not you, here is a pragmatic approach.

Start With Two Tools

GitHub Actions for CI handles building, testing, and code quality checks. The free tier includes 2,000 minutes per month for private repositories — enough for most small teams. GitLab CI/CD and Bitbucket Pipelines offer similar free tiers.

\DeployHQ for CD handles getting your code onto servers. It connects to your GitHub repository, runs build commands on deployment, and transfers files to your servers over SSH, SFTP, or to cloud storage. The separation between CI and CD tools means you can swap either one independently.

For a comparison of deployment tools available, the best software deployment tools guide covers the landscape.

What You Do Not Need (Yet)

Jenkins : Powerful but requires its own server, maintenance, and plugin management. Overkill for teams under 10.
ArgoCD/Flux : GitOps controllers for Kubernetes. If you are not running Kubernetes, skip these entirely.
Custom deployment scripts : They work until they do not. A managed tool like DeployHQ eliminates an entire class of it works on my machine deployment bugs.
Microservices : A monolith with a clean CI/CD pipeline ships faster than microservices with manual deployments.

Cost Considerations

Tool	Free tier	Paid from
GitHub Actions	2,000 min/month (private)	$0.008/min overage
GitLab CI/CD	400 min/month	$10/month for 10,000 min
\DeployHQ	1 project, 5 deploys/day	From $4/month
Bitbucket Pipelines	50 min/month	$15/month for 2,500 min

A small team can run a complete CI/CD pipeline for under $20/month. Start there. Add complexity — and cost — only when you have evidence that you need it.

Get Started

A good CI/CD pipeline does not have to be complicated. Start with automated tests on every push, a single staging environment, and a reliable deployment tool. Add deployment strategies, security scanning, and performance optimization as your team and application grow.

Sign up for \DeployHQ to handle the deployment side of your pipeline. Connect your repository, configure your server, and deploy with confidence.

If you have questions about setting up your pipeline or need help with your deployment configuration, reach out to us at support@deployhq.com or find us on Twitter at @deployhq.

Best Software Deployment Tools in 2026

DeployHQ — Fri, 13 Mar 2026 11:38:59 +0000

Choosing a deployment tool is one of those decisions that shapes your entire workflow. Pick the wrong one and you'll spend more time fighting your tooling than shipping features.

The problem is that deployment tool means different things to different teams. A Rails developer deploying to a VPS needs something completely different from a platform team managing Kubernetes clusters. A freelancer shipping WordPress sites has different requirements to an enterprise running blue-green deployments across multiple regions.

This guide compares the most popular software deployment tools in 2026, organized by what you're actually deploying to — so you can skip straight to the category that fits your setup.

How we evaluated these tools

We assessed each tool across five criteria:

Setup complexity : How long does it take to go from zero to first deployment?
Deployment targets : What can you deploy to? (Servers, containers, CDN, PaaS)
Build support : Can the tool run build commands before deployment?
Rollback capability : How quickly can you undo a bad deployment?
Pricing : What does it actually cost for a small team (1-5 developers)?

Quick comparison

Tool	Best for	Deploys to	Build pipeline	Free tier	Starting price
DeployHQ	Teams deploying to their own servers	SSH, SFTP, S3, DigitalOcean Spaces	Yes	1 project	$4/mo
Octopus Deploy	Enterprise CD with complex release orchestration	Servers, Kubernetes, cloud services	Limited (CI separate)	10 targets	$13/mo
AWS CodeDeploy	AWS-native deployments	EC2, ECS, Lambda	No (use CodeBuild)	Free with AWS	AWS costs only
Netlify	Static sites and Jamstack	Netlify CDN	Yes	100GB bandwidth	$19/mo
Vercel	Next.js and frontend frameworks	Vercel Edge Network	Yes	100GB bandwidth	$20/mo
Railway	Full-stack apps on managed infra	Railway containers	Yes	$5 credit	$5/mo
GitHub Actions	CI/CD tightly integrated with GitHub	Anywhere (via scripts)	Yes	2,000 min/mo	$4/user/mo
Argo CD	GitOps for Kubernetes	Kubernetes clusters	No (CI separate)	Free (open source)	Free

Best for deploying to your own servers

DeployHQ

DeployHQ is a dedicated deployment tool built specifically for teams that deploy to servers they control — VPS instances, cloud servers, shared hosting, or on-premise hardware.

How it works : Connect your Git repository (GitHub, GitLab, Bitbucket, or any Git remote), configure your server connection (SSH, SFTP, FTP, or cloud storage), and DeployHQ handles the rest. When you push to a designated branch, DeployHQ runs your build commands, transfers only the changed files, and executes any post-deployment scripts on your server.

Strengths:

Setup takes minutes, not hours — connect repo, add server, deploy
Build pipelines run compilation and dependency installation on DeployHQ's servers
Only transfers changed files (not full re-uploads), making deployments fast
Zero-downtime deployments via atomic symlink switching
One-click rollback to any previous deployment
Works with any server you can connect to over SSH or SFTP
Deploy from GitHub, GitLab, or Bitbucket with automatic triggers

Limitations:

Not designed for container orchestration (Docker, Kubernetes)
No built-in CI (pair with GitHub Actions or GitLab CI for testing)
UI-focused — less scriptable than CLI-first tools

Pricing : Free for 1 project. Paid plans from $4/month for 5 projects. See pricing.

Best for : Web agencies, freelancers, and development teams deploying PHP, Ruby, Python, Node.js, or static sites to VPS or cloud servers. Especially strong for teams managing multiple client projects who need a simple, reliable deployment workflow without DevOps overhead.

Octopus Deploy

Octopus Deploy is an enterprise-grade continuous delivery platform focused on release orchestration — managing complex deployments across multiple environments, approval workflows, and compliance requirements.

How it works : Octopus sits downstream of your CI server. Your CI pipeline (Jenkins, GitHub Actions, TeamCity) produces a package, and Octopus handles deploying that package through your environments (dev → staging → production) with configurable approval gates, variable management, and runbooks.

Strengths:

Powerful release orchestration with multi-environment promotion
Deployment targets include servers, Kubernetes, Azure, AWS, and more
Runbooks for operational tasks beyond deployment
Tenanted deployments for SaaS vendors deploying to multiple customers
Strong audit logging and compliance features

Limitations:

Complex setup — expect hours to days for initial configuration
Requires a separate CI tool (doesn't build or test code)
Pricing scales with deployment targets, which can get expensive
Overkill for small teams or simple deployment workflows

Pricing : Free for up to 10 deployment targets. Cloud plans from $13/month. Self-hosted available.

Best for : Enterprise teams with complex release processes, multiple environments, and compliance requirements. SaaS companies deploying to customer-specific infrastructure.

Best for AWS-native deployments

AWS CodeDeploy

AWS CodeDeploy automates deployments to EC2 instances, ECS containers, and Lambda functions. It's part of the broader AWS developer tools suite (CodePipeline, CodeBuild, CodeCommit).

How it works : You define a deployment configuration (appspec.yml) that tells CodeDeploy how to stop the old version, install the new one, and start it up. CodeDeploy handles rolling deployments, blue-green deployments, and automatic rollback based on CloudWatch alarms.

Strengths:

Native integration with all AWS services
Blue-green deployments for EC2 and ECS
Automatic rollback on deployment failure or alarm triggers
No additional cost (you pay only for the underlying AWS resources)
Works with Auto Scaling groups

Limitations:

AWS-only — doesn't deploy to non-AWS infrastructure
Requires significant AWS knowledge to configure
No build capability (use CodeBuild or an external CI tool)
Configuration via YAML and CLI — no visual deployment dashboard
Steep learning curve compared to dedicated deployment tools

Pricing : Free. You pay only for the AWS resources you use.

Best for : Teams already invested in the AWS ecosystem who want tight integration with EC2, ECS, and Lambda without adding another vendor.

Best for static sites and frontend frameworks

Netlify

Netlify pioneered the Jamstack deployment model: push to Git, Netlify builds your site, and deploys it to a global CDN. It handles static sites, serverless functions, and edge computing.

How it works : Connect your repository, configure a build command (e.g., npm run build), and every push triggers a new deployment. Netlify serves your site from its CDN with automatic HTTPS, form handling, and serverless functions.

Strengths:

Deploy previews for every pull request
Instant rollback (every deployment is immutable)
Built-in forms, identity, and serverless functions
Split testing (A/B deployments)
Global CDN with automatic HTTPS

Limitations:

Built for static sites and Jamstack — not for traditional server-side applications
Serverless functions have execution limits (10-second timeout on free tier)
Bandwidth limits can surprise you on popular sites
Vendor lock-in for Netlify-specific features (forms, identity)

Pricing : Free tier with 100GB bandwidth. Pro from $19/month per member.

Best for : Static sites, Jamstack applications, and marketing sites built with frameworks like Gatsby, Hugo, Next.js (static export), or Eleventy.

Vercel

Vercel is the company behind Next.js, and their platform is optimized for deploying Next.js applications — though it supports other frameworks too.

How it works : Similar to Netlify — connect your repository, push code, and Vercel builds and deploys. The key difference is deep Next.js integration: server-side rendering, API routes, incremental static regeneration, and edge functions all work out of the box.

Strengths:

Best-in-class Next.js support (server components, ISR, middleware)
Edge functions for low-latency server-side logic
Deploy previews with comments for team collaboration
Analytics and speed insights built in
Excellent developer experience and documentation

Limitations:

Optimized for Next.js — other frameworks get fewer features
Pricing can spike with high traffic (bandwidth and function invocations)
Not suitable for traditional backend applications
Vendor lock-in for Vercel-specific features

Pricing : Free tier (hobby). Pro from $20/month per member.

Best for : Next.js applications. If you're building with Next.js, Vercel is the path of least resistance. For other frameworks, evaluate against Netlify and Cloudflare Pages.

Best for full-stack apps on managed infrastructure

Railway

Railway provides a modern PaaS experience: deploy any application (Node.js, Python, Go, Rust, Docker) from a Git repository, and Railway handles the infrastructure — servers, databases, networking, and scaling.

How it works : Connect your repository or push a Docker image. Railway detects your framework, builds your application, and runs it on managed infrastructure. You can add databases (PostgreSQL, MySQL, Redis, MongoDB) with one click.

Strengths:

Deploys almost anything — not limited to static sites
One-click databases and services
Simple pricing based on usage (compute + memory)
Good developer experience with CLI and dashboard
Supports private networking between services

Limitations:

You don't control the underlying infrastructure
Less mature than Heroku or Render for some edge cases
Pricing can be unpredictable for compute-heavy applications
Limited configuration for advanced networking or custom domains

Pricing : $5 one-time credit on the free trial. Usage-based pricing starting from $5/month.

Best for : Side projects, startups, and small teams who want to deploy full-stack applications without managing servers. Good alternative to Heroku.

Best for CI/CD pipelines

GitHub Actions

GitHub Actions is a CI/CD platform built into GitHub. It can build, test, and deploy code triggered by any GitHub event (push, pull request, release, schedule).

How it works : Define workflows in YAML files (.github/workflows/). Each workflow consists of jobs that run on GitHub-hosted or self-hosted runners. You can deploy to any target by writing the appropriate deployment steps — or use pre-built actions from the GitHub Marketplace.

Strengths:

Integrated directly into GitHub — no separate tool to manage
Massive marketplace of pre-built actions
Matrix builds for testing across multiple versions/platforms
Free for public repositories
Self-hosted runners for private infrastructure

Limitations:

Deployment is roll your own — you write the scripts
No deployment dashboard, release history, or one-click rollback
YAML configuration can become complex for multi-environment deployments
Not a deployment tool — it's a CI/CD platform that can deploy

Pricing : Free for public repos (2,000 minutes/month for private). Team plan from $4/user/month.

Best for : Teams already on GitHub who want CI/CD without adding another vendor. Pairs well with a dedicated deployment tool — use GitHub Actions for CI (build + test) and DeployHQ for CD (deployment to servers).

Argo CD

Argo CD is an open-source, GitOps-based continuous delivery tool for Kubernetes. It watches a Git repository containing Kubernetes manifests and automatically syncs them to your cluster.

How it works : You define your desired cluster state in Git (Kubernetes YAML, Helm charts, Kustomize). Argo CD continuously compares the live cluster state to the Git state and can automatically reconcile differences — or alert you to drift.

Strengths:

GitOps model — Git is the single source of truth
Real-time visualization of Kubernetes resources
Automatic drift detection and sync
Multi-cluster support
Open source and free

Limitations:

Kubernetes-only — not for traditional server deployments
Requires understanding of Kubernetes concepts
No CI capability (pair with a CI tool for build and test)
Complex initial setup

Pricing : Free and open source.

Best for : Teams running Kubernetes who want a GitOps workflow. Not relevant if you're deploying to traditional servers.

How to choose the right deployment tool

The decision tree is simpler than most comparison articles make it:

flowchart TD
    A[What are you deploying to?] --> B{Your own servers?}
    B -->|VPS, cloud, on-prem| C[DeployHQ]
    B -->|No| D{Kubernetes?}
    D -->|Yes| E[Argo CD + CI tool]
    D -->|No| F{Static site?}
    F -->|Yes| G{Next.js?}
    G -->|Yes| H[Vercel]
    G -->|No| I[Netlify or Cloudflare Pages]
    F -->|No| J{AWS only?}
    J -->|Yes| K[AWS CodeDeploy]
    J -->|No| L{Want managed infra?}
    L -->|Yes| M[Railway]
    L -->|No| N{Enterprise release orchestration?}
    N -->|Yes| O[Octopus Deploy]
    N -->|No| C

Key questions:

Do you manage your own servers? If you deploy to VPS instances, cloud servers, or on-premise hardware via SSH/SFTP, DeployHQ gives you the simplest path to automated deployments.
Are you running Kubernetes? Use Argo CD or Flux for GitOps-based deployment. These tools are purpose-built for container orchestration.
Is it a static site or Jamstack app? Netlify, Vercel, or Cloudflare Pages. Pick based on your framework — Vercel for Next.js, Netlify or Cloudflare for everything else.
Do you want managed infrastructure? Railway, Render, or Fly.io remove the need to manage servers entirely. Good for startups and side projects.
Do you need enterprise release orchestration? Octopus Deploy handles complex multi-environment promotion, approval gates, and compliance workflows.

Most teams deploying web applications to servers they control will get the most value from DeployHQ — it's focused on doing one thing well: getting your code from Git to your server, reliably, with build pipelines and zero-downtime deployments built in.

Ready to try it? Sign up for DeployHQ and deploy your first project in under 5 minutes — no credit card required.

Questions? Reach out at support@deployhq.com or on Twitter @deployhq.

What Is Software Deployment? A Complete Guide

DeployHQ — Fri, 13 Mar 2026 11:38:53 +0000

Software deployment is the process of moving code from a development environment to a place where it can be used — typically a production server. It's the bridge between writing code and making it available to users.

That might sound straightforward, but in practice, deployment involves configuration, testing, coordination, and risk management. Understanding how deployment works — and how to do it well — is fundamental to shipping software reliably.

This guide covers what software deployment means, the steps involved, common strategies, and how tools like DeployHQ simplify the process.

What does software deployment mean?

At its core, software deployment is the act of taking code that has been written, tested, and approved, and placing it in an environment where it runs for its intended audience. That environment is usually a production server, but it can also be a staging server, a test environment, or a content delivery network.

Deployment is not the same as development. Development is writing the code. Deployment is getting that code running somewhere.

It's also not the same as a release. A deployment is a technical event — moving code to a server. A release is a business event — making a feature available to users. You can deploy code without releasing it (for example, using feature flags to keep new functionality hidden until you're ready). This distinction matters because it means you can deploy frequently and safely, decoupling technical risk from business timing.

Why software deployment matters

Every line of code is worthless until it's running in production. Deployment is what turns development effort into user value, and how you handle it directly affects:

Reliability : A poor deployment process is the single most common cause of production outages. Broken deployments take down websites, corrupt data, and erode user trust.
Speed : Teams that deploy frequently ship features faster, fix bugs sooner, and respond to market changes more quickly. The 2023 DORA report found that elite teams deploy on demand — multiple times per day.
Developer experience : Manual, error-prone deployments create anxiety and slow teams down. Automated deployments free developers to focus on building rather than babysitting releases.
Business outcomes : Faster, safer deployments mean shorter time-to-market, fewer incidents, and happier customers.

The software deployment process

While every team's workflow is different, most deployment processes follow the same general steps:

flowchart LR
    A[Code committed] --> B[Build]
    B --> C[Test]
    C --> D[Stage]
    D --> E[Deploy to production]
    E --> F[Verify & monitor]

1. Code is committed to version control

Deployment starts with code being pushed to a Git repository. This is the trigger — either a developer pushes to a specific branch (like main or production), or a pull request is merged.

Most modern deployment tools, including DeployHQ, can watch your repository and trigger deployments automatically when new commits land on a designated branch.

2. Build

Before code can run on a server, it often needs to be compiled, bundled, or otherwise transformed. This build step might involve:

Compiling TypeScript to JavaScript
Bundling frontend assets with Webpack or Vite
Installing dependencies with npm install or composer install
Running database migrations
Generating static files

Tools like DeployHQ's build pipeline run these commands on a dedicated build server before the result is sent to your production server — keeping your deployment clean and consistent.

3. Test

Automated tests should run before code reaches production. This includes unit tests, integration tests, and sometimes end-to-end tests. If tests fail, the deployment should stop.

In a CI/CD pipeline, testing typically happens in a continuous integration (CI) service like GitHub Actions, GitLab CI, or CircleCI. The deployment tool then takes over for the continuous delivery (CD) part — pushing tested code to your servers.

4. Stage

A staging environment is a replica of production where you verify that everything works as expected before going live. Staging catches issues that automated tests might miss — visual bugs, configuration problems, integration failures.

Not every team uses staging. Smaller teams might deploy directly to production with safeguards like canary deployments or feature flags. But for applications where downtime is costly, a staging step is worth the effort.

5. Deploy to production

This is the moment code reaches your live servers. Depending on your setup, this might involve:

Uploading files via SFTP or SSH
Pulling the latest code from Git on the server
Replacing a running container with an updated image
Swapping traffic between server groups (blue-green deployment)

For teams deploying to their own servers — VPS instances on DigitalOcean, AWS EC2, Hetzner, or on-premise hardware — a tool like DeployHQ handles the file transfer, runs post-deployment commands, and manages the entire workflow through a simple interface.

6. Verify and monitor

Deployment doesn't end when files land on the server. You need to verify that the application is running correctly:

Health checks confirm the application responds
Error monitoring (Sentry, Bugsnag) catches exceptions
Performance monitoring tracks response times
Log aggregation reveals warnings or failures

If something goes wrong, you need the ability to roll back to the previous version quickly.

Software deployment strategies

Not all deployments work the same way. The strategy you choose depends on your risk tolerance, infrastructure, and how much downtime you can accept.

Direct deployment (replace and restart)

The simplest approach: replace the old files with new ones and restart the application. This is what most small teams do, and it works well when:

Your application can tolerate a few seconds of downtime
You have a single server
Deployments are infrequent

The downside is that if something goes wrong, your site is down until you fix it or roll back.

Zero-downtime deployment

Zero-downtime deployment ensures users never see an error page during a release. The new version is prepared alongside the old one, and traffic is switched over only when the new version is ready.

DeployHQ supports this through atomic deployments — uploading new files to a separate directory, then switching a symlink once the upload and build steps are complete.

Blue-green deployment

You maintain two identical production environments: blue (current) and green (new). You deploy to the inactive environment, test it, then switch traffic from blue to green. If anything goes wrong, you switch back instantly.

This requires double the infrastructure but provides the fastest possible rollback.

Canary deployment

Instead of deploying to all servers at once, you deploy to a small subset first (the canary). You monitor that subset for errors, and if everything looks good, you gradually roll out to the rest. This limits the blast radius of a bad deployment.

Rolling deployment

Similar to canary, but you update servers one at a time (or in small batches) until all servers are running the new version. At any point during the rollout, some servers run the old version and some run the new one.

flowchart TD
    A[New version ready] --> B[Deploy to Server 1]
    B --> C{Healthy?}
    C -->|Yes| D[Deploy to Server 2]
    C -->|No| E[Roll back Server 1]
    D --> F{Healthy?}
    F -->|Yes| G[Deploy to Server 3]
    F -->|No| H[Roll back Servers 1-2]
    G --> I[All servers updated]

Common deployment failures (and how to avoid them)

Understanding why deployments fail helps you build a process that prevents them:

Missing dependencies

The code works on your machine because you installed a package months ago. The production server doesn't have it. Fix : Always install dependencies as part of your build step, and never rely on manually installed packages.

Environment configuration drift

Your staging server has different environment variables, a different database version, or a different OS version than production. Fix : Use infrastructure as code and keep environments as identical as possible.

Database migration failures

A migration runs in the wrong order, or a migration assumes data exists that doesn't. Fix : Test migrations against a copy of production data. Make migrations reversible where possible.

File permission issues

Uploaded files have the wrong permissions, so the web server can't read them or the application can't write to a cache directory. Fix : Set file permissions explicitly in your deployment configuration.

It worked in staging

Staging doesn't perfectly mirror production — different traffic patterns, different data volumes, different third-party integrations. Fix : Monitor closely after every production deployment and have a fast rollback plan.

Where deployment fits in the development lifecycle

Software deployment is one stage in a broader workflow. Here's how it connects to the rest:

flowchart LR
    A[Plan] --> B[Develop]
    B --> C[Commit & push]
    C --> D[CI: Build & test]
    D --> E[CD: Deploy]
    E --> F[Monitor]
    F -->|Feedback| A

Plan : Define what to build
Develop : Write the code
Commit & push : Save changes to Git
CI (Continuous Integration): Automatically build and test on every push
CD (Continuous Delivery/Deployment): Automatically deploy tested code to servers
Monitor : Watch for issues, gather feedback, improve

The CI part is typically handled by services like GitHub Actions, GitLab CI, or Jenkins. The CD part — actually getting the code onto your servers — is where DeployHQ fits. It connects to your repository, watches for changes, runs your build commands, and deploys the result to your servers over SSH, SFTP, or to cloud storage.

Deployment automation vs manual deployment

Manual deployment — SSHing into a server, pulling code, running commands by hand — works when you're just starting out. But it doesn't scale:

	Manual deployment	Automated deployment
Consistency	Depends on who runs it	Same process every time
Speed	Minutes to hours	Seconds to minutes
Error rate	High (human error)	Low (scripted)
Audit trail	None unless you document it	Automatic logs
Frequency	Discouraged (too risky)	Encouraged (low risk)
Rollback	Manual and stressful	One-click or automatic

Deployment automation removes the human from the process, making deployments faster, safer, and more frequent. This is what enables teams to deploy daily — or even multiple times per day.

Choosing a deployment approach

The right deployment setup depends on your situation:

Deploying to your own servers (VPS, cloud, on-premise)?You need a tool that connects to your server over SSH or SFTP and handles file transfer, build steps, and configuration. DeployHQ is built for exactly this — it works with any server you can connect to.

Using a Platform-as-a-Service (PaaS)?Platforms like Heroku, Railway, or Render handle deployment as part of their service. You push code, they build and deploy it. Less control, but less setup.

Running containers? Container-based deployments (Docker, Kubernetes) package your application and its dependencies together. You build a container image, push it to a registry, and orchestrate deployment across your infrastructure.

Static sites? Static site generators (Next.js, Hugo, Jekyll) can deploy to CDNs like Cloudflare Pages, Netlify, or Vercel. Build once, serve everywhere.

For many teams — especially those deploying web applications to their own servers — a tool like DeployHQ provides the right balance of automation, control, and simplicity without the complexity of container orchestration or the lock-in of a PaaS.

Software deployment checklist

Before deploying to production, verify:

[] All tests pass in CI
[] Build completes without errors
[] Environment variables are configured correctly
[] Database migrations have been tested
[] Staging deployment has been verified (if applicable)
[] Rollback plan is in place
[] Team is aware of the deployment
[] Monitoring and alerting are active

For a more detailed checklist, see our ultimate deployment checklist.

Getting started with software deployment

If you're deploying for the first time, start simple:

Get your code into Git — if it's not in a Git repository yet, start there
Choose a server — a VPS from DigitalOcean, Hetzner, or AWS is a good starting point
Set up a deployment tool — sign up for DeployHQ, connect your repository, and configure your server
Deploy — push to your deployment branch and watch it go live
Automate — enable automatic deployments so every push triggers a deploy

From there, you can layer on build pipelines, staging environments, zero-downtime deployments, and monitoring as your application grows.

Ready to simplify your deployment workflow? DeployHQ connects to your Git repository and deploys to any server over SSH, SFTP, or to cloud storage — with build pipelines, zero-downtime deployments, and one-click rollbacks built in.

Questions? Reach out at support@deployhq.com or on Twitter @deployhq.