DEV Community: 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.

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.

CLAUDE.md, AGENTS.md, and Every AI Config File Explained

DeployHQ — Wed, 11 Mar 2026 10:07:28 +0000

Every AI coding tool now reads a configuration file from your project. Claude Code looks for CLAUDE.md. Codex CLI reads AGENTS.md. Gemini CLI checks for GEMINI.md. Cursor has .cursorrules. GitHub Copilot uses copilot-instructions.md. Windsurf has .windsurfrules.

These files solve a fundamental problem: AI models have no persistent memory. Every session starts blank. Without a configuration file, you'd repeat the same instructions every time — your tech stack, coding conventions, project structure, deployment rules. These files give your AI assistant the context it needs to produce useful code from the first prompt.

This guide covers every major format, explains how they work, and shows you how to write effective instructions that actually improve your AI's output.

The Complete Landscape

Here's every AI configuration file format in use today:

File	Tool	Location	Format
`CLAUDE.md`	Claude Code	Project root + `~/.claude/`	Markdown
`AGENTS.md`	Codex CLI, Cursor, Claude Code (fallback)	Project root + subdirectories	Markdown
`GEMINI.md`	Gemini CLI	Project root + `~/.gemini/`	Markdown
`.cursorrules`	Cursor (legacy)	Project root	Plain text
`.cursor/rules/*.mdc`	Cursor (current)	`.cursor/rules/` directory	MDC (Markdown+)
`.github/copilot-instructions.md`	GitHub Copilot	`.github/` directory	Markdown
`.github/instructions/*.instructions.md`	GitHub Copilot (scoped)	`.github/instructions/`	Markdown + frontmatter
`.windsurfrules`	Windsurf (legacy)	Project root	Plain text
`.windsurf/rules/*.md`	Windsurf (current)	`.windsurf/rules/` directory	Markdown

Every tool has converged on the same core idea: a markdown file in your repository that the AI reads before doing anything. The differences are in naming and how they handle hierarchy.

How Each Format Works

CLAUDE.md — Claude Code

Claude Code reads CLAUDE.md files from three locations, merged in order:

~/.claude/CLAUDE.md — Your personal global instructions (applied to all projects)
./CLAUDE.md — Project root instructions (shared with your team via git)
Subdirectory CLAUDE.md files — Scoped instructions for specific parts of the codebase

Claude Code also reads AGENTS.md as a fallback if no CLAUDE.md is found in a directory. This means if your team uses multiple AI tools, you can maintain a single AGENTS.md and it will work with Claude Code automatically.

A key constraint: research suggests frontier LLMs can reliably follow around 150-200 instructions. Claude Code's system prompt already uses about 50 of those, so keep your CLAUDE.md concise — ideally under 300 lines.

AGENTS.md — The Cross-Tool Standard

AGENTS.md is the closest thing to a universal standard. Originally popularised by OpenAI's Codex CLI, it's now an open format stewarded by the Linux Foundation with adoption across 60,000+ open-source projects. It's supported by:

Codex CLI (primary config file)
Cursor (reads alongside .cursorrules)
Claude Code (fallback when no CLAUDE.md exists)
Continue.dev , Aider , OpenHands

Codex CLI has the most sophisticated discovery process. It walks from your project root down to the current working directory, checking each level for AGENTS.md (or AGENTS.override.md for local overrides). You can configure fallback filenames and size limits in ~/.codex/config.toml:

project_doc_fallback_filenames = ["TEAM_GUIDE.md", ".agents.md"]
project_doc_max_bytes = 65536

GEMINI.md — Gemini CLI

Gemini CLI uses GEMINI.md with a hierarchical discovery system similar to Codex:

~/.gemini/GEMINI.md — Global defaults for all projects
Workspace root GEMINI.md — Project-level instructions
Subdirectory GEMINI.md files — Discovered dynamically when tools access files in those directories

A unique feature: you can inspect the loaded context at any time with the /memory show command, and force a reload with /memory refresh. The filename itself is configurable via settings.json if you prefer a different name.

.cursorrules / .cursor/rules/ — Cursor

Cursor has evolved through two formats:

Legacy : A single .cursorrules file in the project root. Still supported but deprecated.

Current (recommended): A .cursor/rules/ directory containing multiple .mdc files, each with its own scope:

Always On — Applied to every interaction
Auto Attached — Activated when matching files are open
Model Decision — The AI decides whether to apply based on a description
Manual — Only when explicitly mentioned via @

This is the most granular system — you can have frontend.mdc for React conventions and backend.mdc for API patterns, each activated only when relevant. Create rules quickly with the /rules slash command in Cursor's terminal.

copilot-instructions.md — GitHub Copilot

GitHub Copilot reads from .github/copilot-instructions.md for project-wide instructions. Since July 2025, it also supports scoped instructions via .github/instructions/*.instructions.md files with glob-pattern frontmatter:

---
applyTo: "**/*.tsx"
---
Use functional components with TypeScript interfaces.
Always use server components unless client interactivity is required.

This lets you define different rules for different file types — TypeScript vs Python, frontend vs backend — without cluttering a single file.

.windsurfrules / .windsurf/rules/ — Windsurf

Windsurf follows the same legacy-to-directory evolution as Cursor:

Legacy : .windsurfrules in the project root
Current : .windsurf/rules/ directory with individual rule files

Rules can be Always On , Manual (via @mention), or Model Decision. Note the character limits: individual rule files are capped at 6,000 characters, and total combined rules must not exceed 12,000 characters.

Which One Should You Use?

If your team uses a single AI tool, use that tool's native format. But most teams now use multiple tools — Cursor in the IDE, Claude Code in the terminal, Copilot for quick completions. Here's a practical approach:

your-project/
├── AGENTS.md ← Universal instructions (works with Codex, Cursor, Claude Code)
├── CLAUDE.md ← Claude-specific additions (if needed)
├── .github/
│ └── copilot-instructions.md ← Copilot-specific (if your team uses it)
├── .cursor/
│ └── rules/ ← Cursor-specific scoped rules (if needed)
└── ...

Start with AGENTS.md as your single source of truth. It has the widest cross-tool support. Then add tool-specific files only when you need features that AGENTS.md can't provide (like Cursor's scoped activation or Copilot's glob patterns).

For Claude Code users: you can make your CLAUDE.md simply reference the shared instructions:

Strictly follow the rules in ./AGENTS.md

Writing Effective Instructions

The most common mistake is treating these files like comprehensive documentation. They're not — they're concise instructions that fit within a model's attention window. Here's what works.

What to Include

Build and test commands — The single most valuable thing you can provide:

## Commands
- Build: `npm run build`
- Test single file: `npm test -- path/to/test.ts`
- Lint: `npm run lint`
- Type check: `npx tsc --noEmit`

Tech stack and versions — Prevents the AI from guessing wrong:

## Stack
- Framework: Next.js 15 (App Router)
- Language: TypeScript 5.7 (strict mode)
- Styling: Tailwind CSS 4.0
- Database: PostgreSQL 16 with Drizzle ORM
- Deployment: DeployHQ → Ubuntu 22.04 VPS

Project structure — Especially important for monorepos:

## Structure
- `apps/web/` — Next.js frontend
- `apps/api/` — Express API server
- `packages/shared/` — Shared types and utilities
- `infra/` — Terraform configuration

Critical conventions — Things the AI would otherwise get wrong:

## Conventions
- Use named exports, not default exports
- API routes return { data, error } shape
- Database migrations go in `drizzle/migrations/`
- Environment variables are validated in `src/env.ts`

What to Leave Out

Code style rules — Use ESLint, Prettier, and formatters instead. They're faster, deterministic, and don't consume your instruction budget.

Obvious things — Write clean code and follow best practices waste tokens. Be specific or don't include it.

Full API documentation — Link to it instead. Use a docs/ or agent_docs/ directory for supplementary context that the AI can pull in when needed.

Task-specific instructions — These belong in your prompt, not in a persistent config file.

A Deployment-Focused Example

Here's a complete AGENTS.md for a PHP team using DeployHQ:

## Project: Acme Web App

Laravel 11 application deployed via DeployHQ to Ubuntu 22.04 VPS.
Production: Nginx + PHP-FPM 8.3. Database: MySQL 8.

## Commands
- Run tests: `php artisan test --filter=TestName`
- Run all tests: `php artisan test`
- Lint: `./vendor/bin/pint`
- Static analysis: `./vendor/bin/phpstan analyse`
- DB migrate: `php artisan migrate`

## Deployment Rules
- Never modify production configs directly
- All database migrations must be reversible
- Run migrations before deploying code that depends on schema changes
- Include rollback steps in PR descriptions for risky changes
- Feature flags for anything touching payments or auth
- Run `composer install --no-dev` in production builds

## Structure
- `app/Services/` — Business logic (not in controllers)
- `app/Jobs/` — Background jobs (Laravel Queue)
- `app/Actions/` — Single-purpose action classes
- `deploy/` — DeployHQ build commands
- `tests/` — PHPUnit tests (mirror app/ structure)

## Conventions
- Action classes: single `handle()` method
- API responses: always use `JsonResource` classes
- Logging: use `Log::info()`, never `dd()` or `dump()`
- Secrets: use `config()` helper, never `env()` outside config files
- Validation: FormRequest classes, never inline in controllers

Common Mistakes

Writing a novel. If your config file is over 500 lines, most of it is being ignored. LLMs have limited instruction-following capacity — a focused 50-line file outperforms a sprawling 1,000-line one.

Duplicating across tools. Maintain one source of truth (AGENTS.md) and have tool-specific files reference it. Don't copy-paste the same rules into CLAUDE.md, .cursorrules, and copilot-instructions.md.

Using /init or auto-generators. Auto-generated config files tend to be generic and bloated. Write yours by hand — every line should earn its place by solving a real problem you've encountered.

Including things a linter handles. Use 2-space indentation and always add trailing commas are Prettier's job, not your AI config file's job.

Forgetting to update. These files rot just like any other documentation. When your stack changes, update the instructions. A wrong instruction is worse than no instruction.

Looking to automate your deployment pipeline? DeployHQ deploys code from Git to your servers automatically — one less thing to configure. Get started free.

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

How to Deploy Laravel: Zero Downtime, Build Pipelines, and Best Practices

DeployHQ — Mon, 09 Mar 2026 06:12:29 +0000

Laravel is the most widely used PHP framework, but deploying it involves more than copying files to a server. A typical Laravel deployment requires installing Composer dependencies, compiling frontend assets with Vite, running database migrations, clearing caches, restarting queue workers, and managing environment variables — all without interrupting users.

Get any of those steps wrong and you end up with a white screen, missing assets, or a queue processing stale code.

This guide covers the full Laravel deployment lifecycle: what the build process actually involves, how to choose between deployment tools, how to achieve zero-downtime releases, and the most common deployment failures and how to fix them.

What Laravel Deployment Actually Involves

Laravel is not a static site you can deploy by uploading files. A production-ready deployment typically runs through these steps:

The Build Process

# 1. Install PHP dependencies (without dev packages)
composer install --no-dev --optimize-autoloader --no-interaction

# 2. Install and build frontend assets
npm ci
npm run build

# 3. Cache configuration, routes, views, and events
php artisan optimize

# 4. Run database migrations
php artisan migrate --force

# 5. Create the storage symlink
php artisan storage:link

# 6. Restart queue workers (so they pick up new code)
php artisan queue:restart

Each step matters:

--no-dev excludes testing packages from production, reducing the vendor directory size
npm run build compiles your Vite or Mix assets into the public/build/ directory
php artisan optimize is the unified caching command introduced in Laravel 11 — it replaces the separate config:cache, route:cache, view:cache, and event:cache commands
--force is required for migrations in production (Laravel refuses to run migrations without it outside local environments)
queue:restart signals long-running queue workers to finish their current job and restart, picking up the new code

Server Requirements for Laravel 12

PHP 8.2 or higher
Required extensions: Ctype, cURL, DOM, Fileinfo, Filter, Hash, Mbstring, OpenSSL, PCRE, PDO, Session, Tokenizer, XML
Web server (Nginx or Apache) configured to serve from the public/ directory
Database: MySQL 8.0+, PostgreSQL 10+, SQLite 3.35+, or SQL Server 2017+
Write permissions on storage/ and bootstrap/cache/

Environment Configuration

Laravel uses a .env file for environment-specific settings. This file must never be committed to version control — it contains your application key, database credentials, queue and cache driver configuration, and third-party API keys.

Key production settings:

APP_ENV=production
APP_DEBUG=false
APP_KEY=base64:your-generated-key
APP_URL=https://yourdomain.com

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_DATABASE=your_database
DB_USERNAME=your_user
DB_PASSWORD=your_password

CACHE_DRIVER=redis
QUEUE_CONNECTION=redis
SESSION_DRIVER=redis

Setting APP_DEBUG=false is critical — with debug mode enabled, Laravel exposes full stack traces, environment variables, and database credentials to anyone who triggers an error.

Choosing Your Deployment Strategy

There are several ways to deploy Laravel, from manual SSH commands to fully managed platforms. The right choice depends on whether you already have servers, how much infrastructure you want to manage, and what other tools you use alongside Laravel.

Comparison Table

Feature	Manual SSH	Laravel Forge	Laravel Cloud	DeployHQ	Deployer
Server provisioning	No	Yes	Yes (managed)	No	No
Build pipeline	No	Basic scripts	Yes	Yes (remote servers)	No
Zero-downtime releases	No	Yes (Envoyer add-on)	Yes	Yes (atomic symlinks)	Yes
One-click rollback	No	No	Yes	Yes	Yes
Multi-server deploy	No	No	No	Yes	Yes
Non-PHP project support	N/A	Limited (Node, etc.)	No	Yes (any stack)	No
Web dashboard	No	Yes	Yes	Yes	No (CLI only)
Open source	N/A	No	No	No	Yes
Cost	Free	$12-39/mo	Usage-based	€9-99/mo	Free

Manual Deployment (SSH + Git Pull)

The simplest approach: SSH into your server, pull the latest code, and run the build commands manually.

ssh user@yourserver.com
cd /var/www/myapp
git pull origin main
composer install --no-dev --optimize-autoloader
npm ci && npm run build
php artisan migrate --force
php artisan optimize
php artisan queue:restart

When it works : Solo developer, single server, deploying infrequently.

When it breaks : Teams (who ran the commands last?), multiple servers (repeat everything N times), urgent rollbacks (which files changed?), and Friday afternoon deployments (one wrong command and you are debugging into the evening).

Laravel Forge

Forge provisions and manages servers on DigitalOcean, Hetzner, AWS, or other providers. It handles Nginx configuration, SSL, database setup, and push-to-deploy with customisable deploy scripts.

Best for : Teams that want server management bundled with deployment. Forge handles everything from provisioning to SSL renewal.

Limitations : Deploy scripts run on the production server (no separate build pipeline). Zero-downtime requires the separate Envoyer product ($12/mo extra). Limited to PHP/Node stacks.

Laravel Cloud

Laravel Cloud is fully managed hosting — zero server management, automatic scaling, push-to-deploy from GitHub, and SOC 2 compliance. Launched February 2025.

Best for : Teams that want zero infrastructure management and are building exclusively with Laravel.

Limitations : Vendor lock-in to Laravel's infrastructure. Usage-based pricing that can be hard to predict. Less control over server configuration. Laravel-only.

DeployHQ

DeployHQ is a deployment tool that connects your Git repository to your servers. Build commands run on DeployHQ's infrastructure (not on your production server), and files are deployed via SSH, SFTP, FTP, or S3.

Best for : Teams that already have servers (from any provider) and want automated deployment with build pipelines, zero-downtime releases, and multi-server support. Also ideal when you deploy Laravel alongside other stacks (Node.js frontend, WordPress marketing site, Python microservice).

Key advantage : Build pipeline runs remotely. Your production server does not need Node.js or npm installed — DeployHQ compiles your Vite assets and installs Composer dependencies on its build servers, then deploys only the production-ready files.

For a step-by-step setup walkthrough, see How to Deploy Laravel with DeployHQ.

Deployer

Deployer is a free, open-source PHP deployment tool with a dedicated Laravel recipe that includes 40+ artisan tasks, zero-downtime via symlinks, parallel deployment, and rollbacks.

Best for : Developers who want full control, are comfortable with CLI tools, and prefer open-source solutions.

Limitations : No web dashboard, no build pipeline (builds run on your machine or CI server), steeper learning curve.

For a detailed comparison, see DeployHQ vs Deployer.

Forge + DeployHQ Together

This combination is worth highlighting because it addresses a common misconception: Forge and DeployHQ are not competitors. They solve different problems.

Forge manages your server: provisioning, Nginx config, SSL, database, PHP version, firewall rules
DeployHQ manages your deployment pipeline: build steps, file transfer, zero-downtime release, rollback, notifications

Using both means Forge handles the infrastructure while DeployHQ handles the deployment workflow — with remote build pipelines, one-click rollback, multi-server deployment, and team notifications that Forge's built-in deploy scripts do not offer.

For a detailed comparison, see DeployHQ vs Laravel Forge: How They Differ and How to Use Them Together.

Zero-Downtime Laravel Deployments

Standard deployments cause a brief period of downtime while files are being uploaded and commands are running. For high-traffic applications, this is unacceptable. Zero-downtime deployment eliminates this entirely.

How Atomic Releases Work

Instead of overwriting files in place, atomic releases use a directory structure with a symlink swap:

/var/www/myapp/
├── releases/
│ ├── 20260301120000/ ← previous release
│ ├── 20260302150000/ ← current release (live)
│ └── 20260303090000/ ← new release (being prepared)
├── current → releases/20260302150000/ ← symlink
├── shared/
│ ├── storage/ ← persists across releases
│ └── .env ← persists across releases

The deployment process:

flowchart TD
    A[Clone new release] --> B[Install dependencies]
    B --> C[Build assets]
    C --> D[Run migrations]
    D --> E[Swap symlink]
    E --> F[Live traffic served]
    style E fill:#1abc9c,color:#fff

A new release directory is created
Code is deployed into this directory
Dependencies are installed and assets are built
Shared directories (storage, .env) are symlinked into the new release
Database migrations run against the new release
The current symlink is atomically swapped to point to the new release
If anything fails before the swap, current still points to the previous working release

The symlink swap is an atomic filesystem operation — there is no moment where the application is in a broken state.

Shared Files and Directories

Some files and directories must persist across releases:

.env — environment configuration (database credentials, API keys)
storage/ — logs, uploaded files, cache, sessions
bootstrap/cache/ — sometimes shared depending on your setup

DeployHQ handles this automatically when you enable zero-downtime deployments — you configure which paths are shared, and the symlinks are managed for you.

Instant Rollback

With atomic releases, rolling back means changing the current symlink to point at the previous release directory. This takes milliseconds. No files are modified, no git reverts, no partial states.

In DeployHQ, rollback is a single click in the deployment history.

Laravel Deployment Checklist

Use this checklist before every production deployment:

[] APP_ENV=production and APP_DEBUG=false are set
[] APP_KEY is generated and set (never commit this to Git)
[] composer install --no-dev --optimize-autoloader runs without errors
[] Frontend assets compile with npm run build — check public/build/ exists
[] Database migrations tested in staging first
[] php artisan optimize runs after deployment (caches config, routes, views, events)
[] Queue workers restart after deployment (php artisan queue:restart)
[] storage/ and bootstrap/cache/ have correct write permissions
[] Nginx or Apache serves from the public/ directory only
[] .env, .git/, and storage/ are not web-accessible
[] Health check endpoint (/up) responds correctly
[] Deployment notifications configured (Slack, Discord, or email)
[] Zero-downtime deployments enabled for production
[] At least 3-4 previous releases kept for rollback
[] Queue workers monitored with Supervisor or Laravel Horizon

Troubleshooting Common Deployment Issues

500 Server Error After Deployment

The most common cause: missing .env file or APP_KEY. Laravel cannot boot without an application key.

Check first :

Does .env exist in the deployment directory?
Is APP_KEY set? Run php artisan key:generate --show to verify.
Clear cached config: php artisan config:clear && php artisan cache:clear
Check storage/logs/laravel.log for the actual error message.
Verify storage/ has write permissions: chmod -R 775 storage bootstrap/cache

Assets Not Loading (CSS/JS 404 Errors)

Frontend build did not run or the Vite manifest is missing.

Check :

Does public/build/manifest.json exist? If not, npm run build did not complete.
If using DeployHQ, verify the build command (npm ci && npm run build) is in your build pipeline.
Check that APP_URL in .env matches your actual domain — Vite uses this to generate asset URLs.
If assets load on HTTP but not HTTPS, set ASSET_URL=https://yourdomain.com in .env.

Database Migration Failures

Migrations failing in production while working locally.

Check :

Did you include --force? Laravel refuses to migrate in production without it.
Use php artisan migrate --pretend to preview SQL without executing.
Never run destructive migrations (dropping columns or tables) without a rollback plan.
For large tables, consider running schema changes during low-traffic periods.

Queue Workers Serving Old Code

After deployment, queue workers continue processing jobs with the old application code because they cache the application state in memory.

Fix : Add php artisan queue:restart to your post-deployment commands. This signals workers to finish their current job, then restart with the new code.

If using Laravel Horizon, restart Horizon instead:

php artisan horizon:terminate

Supervisor (or your process manager) will automatically restart it.

Storage Symlink Not Working After Zero-Downtime Deploy

The public/storage symlink points to storage/app/public, but after a zero-downtime deployment, the path has changed because the release directory is new.

Fix : Configure storage as a shared directory in your zero-downtime settings. The symlink should point to the shared storage/ path, not the release-specific one. Then run php artisan storage:link in your post-deployment commands.

Getting Started

If you already have a server, the fastest path to automated Laravel deployment is:

Sign up for DeployHQ (free trial, no credit card)
Connect your Git repository
Add your server (SSH or SFTP)
Set up build commands: composer install --no-dev --optimize-autoloader && npm ci && npm run build
Add post-deploy SSH commands: php artisan migrate --force && php artisan optimize && php artisan queue:restart
Enable auto-deploy on push to your main branch
Deploy

For a detailed walkthrough with screenshots, see How to Deploy Laravel with DeployHQ. For help choosing between Forge and DeployHQ, see DeployHQ vs Laravel Forge.

Questions about deploying Laravel? Reach out at support@deployhq.com or on Twitter/X.

How to Deploy and Configure OpenClaw on a VPS

DeployHQ — Fri, 06 Mar 2026 18:21:56 +0000

OpenClaw is one of the fastest-growing open-source projects of 2026 — 247,000 GitHub stars and counting. It acts as a self-hosted gateway between the messaging apps you already use (WhatsApp, Telegram, Discord, Slack) and AI models like Claude or GPT-4. Instead of paying for yet another SaaS AI assistant, you run it on your own VPS, keep your data private, and pay only for the API calls you actually make.

This guide walks you through setting up OpenClaw on a Ubuntu VPS from scratch: provisioning, security hardening, Nginx with SSL, systemd service management, and automating configuration deployments with DeployHQ.

What You'll Need

A VPS running Ubuntu 22.04 LTS (minimum 2 vCPU, 4 GB RAM, 20 GB SSD — DigitalOcean, Contabo, or Hetzner all work)
A domain name pointed at your VPS IP
An API key from an AI provider (Anthropic, OpenAI, or Google Gemini)
An account on your preferred messaging platform (Telegram is the easiest to start with)
A DeployHQ account for automating updates (free tier covers this)

Step 1 — Initial Server Setup

Connect as root, then immediately create a non-root user with sudo access:

ssh root@<your-vps-ip>

adduser openclawops
usermod -aG sudo openclawops

Copy your SSH key to the new user so you can log back in without a password:

rsync --archive --chown=openclawops:openclawops ~/.ssh /home/openclawops

Switch to the new user for all remaining steps:

su - openclawops

Tighten SSH configuration to disable password auth and root login:

sudo nano /etc/ssh/sshd_config

Set these values:

PasswordAuthentication no
PermitRootLogin no

Restart SSH (keep your current session open in case something goes wrong):

sudo systemctl restart ssh

Update the system before doing anything else:

sudo apt update && sudo apt dist-upgrade -y

Step 2 — Configure the Firewall

Lock down ingress traffic with UFW. Allow only SSH, HTTP, and HTTPS:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw limit 22/tcp # rate-limit to slow brute-force attempts
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

Verify the rules are active:

sudo ufw status verbose

Do not open port 18789 (OpenClaw's gateway port) to the public internet. We'll put Nginx in front of it.

Step 3 — Install Node.js 22

OpenClaw requires Node.js ≥22. Install it from the NodeSource repository:

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs
node --version # should print v22.x.x

Step 4 — Install OpenClaw

Run the official installer. It will walk you through an interactive setup wizard:

curl -fsSL https://openclaw.ai/install.sh | bash

During the wizard:

Accept the risk acknowledgment
Choose QuickStart mode
Enter your AI provider API key (Anthropic, OpenAI, or Gemini)
Select your messaging channel — Telegram is recommended for VPS setups since it doesn't require port forwarding
Enable bash completion

Once installed, verify the gateway started correctly:

openclaw gateway status

You should see the gateway bound to 127.0.0.1:18789. If it shows 0.0.0.0:18789, fix that immediately — the gateway would be publicly accessible without authentication.

Step 5 — Bind the Gateway to Localhost

If the gateway is listening on all interfaces, rebind it:

openclaw configure

When prompted for the gateway binding, select Local (this machine). This ensures the gateway only accepts connections from 127.0.0.1, and all external access goes through Nginx.

Step 6 — Set Up Nginx as a Reverse Proxy

Install Nginx and Certbot:

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

Create a new server block for OpenClaw:

sudo nano /etc/nginx/sites-available/openclaw

Paste the following, replacing openclaw.example.com with your actual domain:

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

    location / {
        proxy_pass http://127.0.0.1:18789;
        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_read_timeout 86400;
    }
}

The proxy_read_timeout 86400 (24 hours) prevents Nginx from closing long-running WebSocket connections that OpenClaw uses for real-time messaging.

Enable the site and test the config:

sudo ln -s /etc/nginx/sites-available/openclaw /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

Obtain a free TLS certificate from Let's Encrypt:

sudo certbot --nginx -d openclaw.example.com

Certbot automatically reconfigures Nginx for HTTPS and sets up auto-renewal. Your gateway is now accessible at https://openclaw.example.com with a valid certificate.

Step 7 — Run OpenClaw as a Systemd Service

Right now OpenClaw stops when you close your SSH session. Fix that by creating a systemd unit:

sudo nano /etc/systemd/system/openclaw.service


[Unit]
Description=OpenClaw Gateway
After=network.target

[Service]
Type=simple
User=openclawops
WorkingDirectory=/home/openclawops
ExecStart=/usr/bin/openclaw gateway start
Restart=on-failure
RestartSec=5
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target

Enable and start the service:

sudo systemctl daemon-reload
sudo systemctl enable openclaw
sudo systemctl start openclaw
sudo systemctl status openclaw

OpenClaw now starts automatically on boot and restarts if it crashes.

Step 8 — Connect Your Messaging Channel

With the gateway running, add a Telegram bot:

Open Telegram and message @botfather
Run /newbot and follow the prompts — you'll receive a bot token
On your server, run:

openclaw channels add telegram

Enter the bot token when prompted. Send your bot a message on Telegram — OpenClaw should respond immediately via whichever AI provider you configured.

Step 9 — Automate Configuration Updates with DeployHQ

As you customise OpenClaw — adding Skills (plugins for Gmail, GitHub, Notion, Home Assistant, and 100+ others), tweaking system prompts, or updating webhook configs — you'll want those changes deployed to your VPS automatically rather than manually SSH-ing in.

The pattern is straightforward: store your OpenClaw configuration and custom skills in a Git repository, then use DeployHQ to deploy changes to your VPS whenever you push.

Set up your config repository:

mkdir ~/openclaw-config && cd ~/openclaw-config
git init

# Copy any custom skills or config overrides into this directory
cp ~/.openclaw/config.json ./config.json
cp -r ~/.openclaw/skills ./skills

Create a deployment script (deploy.sh) that your VPS runs on every push:

#!/bin/bash
set -e

# Copy config updates into place
cp config.json ~/.openclaw/config.json
rsync -av skills/ ~/.openclaw/skills/

# Restart the gateway to pick up changes
sudo systemctl restart openclaw

echo "OpenClaw updated and restarted"

Push this to your Git host (GitHub, GitLab, Bitbucket, or Codebase):

git add .
git commit -m "Initial OpenClaw config"
git remote add origin <your-repo-url>
git push -u origin main

Connect DeployHQ:

Log in to DeployHQ and create a new project
Connect it to your repository
Add your VPS as a server (SSH key authentication)
Set the deployment path to /home/openclawops/openclaw-config
Add a post-deployment command: bash deploy.sh

Now every time you push a config change or add a new skill, DeployHQ runs the deployment automatically. No more SSH sessions for routine updates — and you get a full deployment history with rollback if something breaks.

This same workflow applies to any Node.js application you're running on your VPS. DeployHQ supports deploying Node.js apps alongside OpenClaw, so you can manage multiple services on the same server from a single dashboard. You can also use DeployHQ to deploy Python-based tools — for instance, scraping applications with ScraperAPI and DeployHQ for automated data collection alongside your AI assistant.

Keeping OpenClaw Updated

OpenClaw releases frequently. To upgrade the CLI itself:

npm update -g openclaw
sudo systemctl restart openclaw

Check the OpenClaw GitHub releases for breaking changes before upgrading on production.

Troubleshooting

Gateway won't start : Check logs with journalctl -u openclaw -n 50. Most failures are missing environment variables (API key not set) or port conflicts.

Nginx 502 Bad Gateway : The OpenClaw gateway isn't running. Run openclaw gateway status and check systemd logs.

Telegram bot not responding : Verify the bot token is correct with openclaw channels list. Also check that your VPS can reach api.telegram.org — some providers block outbound traffic by default.

Certificate renewal failing : Run sudo certbot renew --dry-run to debug. Certbot needs ports 80 and 443 open and Nginx running.

Frequently Asked Questions

Do I need a domain name?

No — you can skip Steps 6 entirely and access the Control UI via an SSH tunnel instead:

ssh -N -L 18789:127.0.0.1:18789 openclawops@<your-vps-ip>

Then open http://localhost:18789 in your browser. The downside is you need the tunnel running whenever you want to use the web UI. If you're using Telegram or another messaging channel, those work fine without any web access.

Which AI provider should I use?

Anthropic's Claude is the most capable for complex tasks and follows instructions precisely. OpenAI's GPT-4o is a solid all-rounder and has slightly broader third-party skill compatibility. Google Gemini Flash is the cheapest option for high-volume use. You can configure multiple providers and switch between them per conversation — useful if you want cheaper models for quick queries and stronger ones for coding tasks.

Can multiple people share one OpenClaw instance?

Yes. OpenClaw supports multiple channels and workspace isolation, so you can connect separate Telegram bots or Slack workspaces and route them to different agent configurations. Each workspace gets its own memory, system prompt, and tool access. This is useful for teams where each member wants their own assistant context without running separate VPS instances.

How much will API costs actually run?

For typical personal use — a few dozen queries per day — expect $5–$15/month in API costs on top of your VPS bill. Heavy use with Claude Opus or GPT-4 can push that higher. Switching to Claude Haiku or Gemini Flash for routine tasks and reserving the stronger models for complex ones is the most effective way to keep costs in check. OpenClaw logs every API call with token counts, so you can monitor usage from the Control UI.

Is my data private if I use a cloud AI provider?

Your messages are sent to whichever AI provider's API you configure. OpenClaw itself keeps all session history and memory on your VPS — nothing is stored by third parties beyond what the AI API processes to generate a response. If you need full end-to-end privacy, you can run a local model (via Ollama) and point OpenClaw at it — your data then never leaves the VPS.

Can I run other services on the same VPS?

Yes. OpenClaw runs as a single Node.js process and is relatively lightweight — a 4 GB RAM server comfortably runs OpenClaw alongside a small web app, database, or other services. Use separate Nginx server blocks for each service and manage them all through DeployHQ.

How do I back up my OpenClaw configuration?

The configuration the DeployHQ workflow covers is the primary backup strategy — your config.json and custom skills live in Git, which is your source of truth. For session memory and conversation history stored by OpenClaw locally, back up the ~/.openclaw/data directory periodically. A simple cron job to rsync it to an S3-compatible bucket is sufficient for most setups.

What happens when OpenClaw releases a breaking update?

Check the CHANGELOG before running npm update -g openclaw. Breaking changes are rare but do happen — usually around skill API changes. Test on a staging VPS first if you have critical automations running, then update production. The Restart=on-failure in your systemd unit means even a bad update that crashes the process won't leave you without a running service — it'll keep retrying until you fix the config.

OpenClaw gives you a genuinely useful AI assistant that runs on infrastructure you control — no subscription lock-in, no data leaving your servers unless you choose it. A $5-$10/month VPS handles typical personal use comfortably, and your only ongoing cost is API usage.

For teams managing multiple VPS instances, DeployHQ simplifies keeping configurations consistent across servers — deploy once to all your nodes from a single push. Sign up free and connect your first server in minutes.

Have questions or hit an issue? Reach out at support@deployhq.com or find us on Twitter at @deployhq.

Game Panel Integration: Deploy to Your Game Server from Git

DeployHQ — Fri, 06 Mar 2026 08:09:47 +0000

If you run a Minecraft, Rust, Garry's Mod, or FiveM server, you're probably familiar with the routine: download a plugin update, open FileZilla, connect via SFTP, navigate to the right folder, upload, restart, and hope nothing breaks.

Now multiply that across multiple servers, multiple admins, and dozens of plugins. One wrong config file overwrites another, there's no record of who changed what, and rolling back means restoring from a backup — if you even have one.

We're introducing Game Panel integration to DeployHQ, starting with native support for the Pterodactyl protocol. This means you can deploy plugins, mods, configs, and scripts to your game server directly from Git — with automatic deployments on push, full deployment history, and one-click rollback.

Why deploy your game server from Git?

If you're managing a community Minecraft server with 30+ plugins, a DarkRP Garry's Mod server with custom Lua addons, or a Rust server with uMod configurations, you're managing a codebase — whether you think of it that way or not.

Version control with Git gives you:

Full history of every change. Know exactly when a plugin was updated, which config was modified, and who did it. No more who changed server.properties?
Instant rollback. A plugin update breaks your server? Revert to the last working deployment in DeployHQ with one click. No digging through backup archives.
Branches for testing. Set up a test server alongside your production server. Make changes in a branch, test them, then merge and deploy to production when you're confident.
Team coordination. Multiple admins can work on configs in their own branches and merge via pull requests. No more stepping on each other's changes over SFTP.

This is how professional development teams have worked for decades. Game server admins deserve the same workflow.

How it works

The setup takes about five minutes:

Put your server files in a Git repository. Your plugins, mods, configs, and custom scripts go in a Git repo on GitHub, GitLab, or Bitbucket. World files, player data, and logs stay out (add them to .gitignore).
Create a DeployHQ project. Connect your repository and add your game server — either using SFTP credentials from your hosting panel, or with the new Pterodactyl protocol for hosts that run Pterodactyl.
Push to deploy. Every time you push to your repository, DeployHQ uploads only the files that changed to your game server. No full re-uploads, no missed files.

That's it. No YAML files to write, no CI/CD pipelines to configure, no SFTP credentials saved in browser bookmarks.

Pterodactyl protocol support (beta)

Pterodactyl is the open-source game server management panel used by dozens of hosting providers. If your host's panel lets you manage your server through a web interface with a file manager, console, and power controls — there's a good chance it runs on Pterodactyl (or one of its forks like Pelican or Pyrodactyl).

Hosts running Pterodactyl include:

BisectHosting (branded as Starbase Panel)
PebbleHost
Bloom.host
GGServers
Sparked Host
And many more

Until now, connecting DeployHQ to a Pterodactyl-based server meant configuring SFTP manually — finding the right hostname, using port 2022 instead of the standard 22, and figuring out the username format (username.serverid).

With the new Pterodactyl protocol, DeployHQ connects natively. Select Game Panel as your server type, enter your panel URL and API credentials, and DeployHQ handles the rest.

What can you deploy?

Anything that lives on your game server's filesystem:

File type	Examples	Games
Plugins	.jar files (Spigot, Paper, Bukkit), .cs files (uMod, Carbon), .lua scripts	Minecraft, Rust, GMod
Mods	Forge/Fabric mods, BepInEx plugins, modpack configs	Minecraft, Valheim
Configurations	server.properties, YAML/JSON configs, game settings	All games
Custom scripts	Lua addons, DarkRP configs, FiveM resources	GMod, FiveM
Maps and worlds	Custom maps, level files	Minecraft, ARK, CS2

Use Excluded files to keep server-generated content (world saves, player data, logs) out of your deployments. Use Config files to manage server-specific settings that shouldn't live in your repository.

The alternative: 50 lines of YAML

The only other way to automate game server deployments today is to build a CI/CD pipeline yourself using GitHub Actions. GGServers published a guide for this — it involves writing a YAML workflow file, storing SFTP credentials as GitHub Secrets, configuring LFTP mirror commands, and managing file exclusion patterns manually.

It works, but it requires DevOps knowledge that most game server admins don't have (and shouldn't need). There's no deployment history UI, no rollback button, no way to see what was deployed and when without reading CI logs.

DeployHQ replaces all of that with a configured server connection and a deploy button.

Works with every game server host

Game Panel integration with Pterodactyl is just the beginning. DeployHQ already connects to any game server with FTP or SFTP access — which is virtually all of them.

We have step-by-step guides for connecting to:

Apex Hosting (FTP, port 21)
BisectHosting (SFTP, port 2022)
GPortal (FTP/SFTP)
Nitrado (FTP/SFTP, port 21)
Nodecraft (FTPS, port 121)
PebbleHost (SFTP, port 2022)
Physgun (SFTP)
Shockbyte (SFTP)

Running your own server on a VPS? Connect via SSH/SFTP as usual — we have guides for DigitalOcean, Hetzner, Akamai (Linode), and many more.

Getting started

Sign up for a free DeployHQ account
Connect your Git repository (GitHub, GitLab, or Bitbucket)
Add your game server — via Game Panel (Pterodactyl), SFTP, or FTP
Push a commit and watch it deploy

No more FileZilla. No more manual uploads. No more who broke the server?

Frequently asked questions

Do I need SSH access to my game server? No. DeployHQ works with FTP and SFTP, which virtually every game server host provides. SSH is not required. If your host runs Pterodactyl, the upcoming Game Panel integration makes setup even easier.

Will DeployHQ restart my server after deploying?Not automatically via SFTP/FTP — you'll restart from your game panel after deployment. With the Pterodactyl Game Panel integration, we're exploring webhook-based restart support so your server can restart automatically after a successful deployment.

Can I deploy to multiple servers at once? Yes. Add multiple servers to your DeployHQ project and deploy to all of them with a single push. This is useful for server networks or test/production setups.

What if a deployment breaks my server? Use DeployHQ's rollback feature to revert to the last working deployment in one click. Every deployment is recorded, so you can always go back to a known good state.

Should I put my entire server in Git? No — only put files you actively manage in your repository. Plugins, mods, configs, and custom scripts belong in Git. World saves, player data, logs, and server-generated files should be excluded using a .gitignore file and DeployHQ's Excluded files feature.

Does this work with modpacks? Yes. Store your modpack configuration (mod JARs, config files, resource packs) in a Git repository and deploy as normal. For large modpacks with hundreds of files, DeployHQ only uploads files that have changed — so updates are fast even on large servers.

Is DeployHQ free?DeployHQ offers a free plan for personal projects with 1 project and 3 deployments per day. Paid plans start at €9/month with unlimited deployments and a free 10-day trial — no credit card required.

I use Multicraft, not Pterodactyl. Can I still use DeployHQ?Yes. The Game Panel integration is specifically for Pterodactyl-based hosts, but DeployHQ connects to any server via standard FTP or SFTP — regardless of which control panel your host uses.

Have questions about deploying to your game server? Contact our support team or reach out on Twitter.

Deployment Agents Compared: DeployHQ vs Buddy vs Octopus Deploy

DeployHQ — Wed, 04 Mar 2026 13:29:00 +0000

When your servers sit behind a firewall, most deployment tools cannot reach them. The standard fix is a deployment agent — a lightweight process that runs inside your private network, connects outbound to the deployment platform, and routes deployment traffic through that tunnel.

Several tools offer this pattern, but the implementations differ significantly. This guide compares three deployment agents side by side: the DeployHQ Agent, the Buddy Proxy Agent, and the Octopus Deploy Polling Tentacle — covering architecture, setup, protocols, security, pricing, and the scenarios where each one fits best.

If you are not sure whether you need a deployment agent in the first place, read our guide on how to deploy to servers behind a firewall, which compares agents against SSH tunnels, VPNs, bastion hosts, and self-hosted CI/CD runners.

How Deployment Agents Work

All three tools solve the same fundamental problem: your deployment platform lives in the cloud, your server lives behind a firewall, and the firewall blocks inbound connections.

The solution is to flip the direction. Instead of the platform connecting inbound to your server, an agent on your server connects outbound to the platform. Since firewalls typically allow outbound traffic, the connection goes through. The platform then sends deployment instructions back through this established tunnel.

flowchart LR
    A[Agent] -->|Outbound connection| B[Platform]
    B -->|Deploy traffic| A
    A -->|Local network| C[Server]
    style A fill:#1abc9c,color:#fff

Where the three tools diverge is in the tunnel protocol, the agent-to-server relationship, and the scope of what the platform does beyond deployment.

Architecture Comparison

DeployHQ Agent: One Tunnel, Any Protocol

The DeployHQ Agent establishes a persistent outbound TLS connection to agent.deployhq.com on TCP port 7777. Once the tunnel is up, DeployHQ routes deployment traffic through it using whatever protocol the deployment target requires — FTP, SFTP, SSH, or S3.

flowchart LR
    A[DeployHQAgent] -->|TLS port 7777| B[DeployHQ]
    B -->|FTP/SFTP/SSH/S3| A
    A -->|Any protocol| C[Server1]
    A -->|Any protocol| D[Server2]
    A -->|Any protocol| E[Server3]
    style A fill:#1abc9c,color:#fff

The agent acts as a network proxy. One agent instance can deploy to multiple internal servers — you control which ones via an access file (~/.deploy/agent.access) that accepts individual IPs, hostnames, or CIDR ranges like 192.168.1.0/24.

Key technical details:

Tunnel protocol : TLS over TCP (port 7777 outbound)
Deployment protocols : FTP, SFTP, SSH, S3 — protocol-agnostic
Agent-to-server ratio : One agent, many servers (proxy model)
Runtime : Ruby 2.2+
Platforms : Linux, macOS, Windows
Open source : Yes — deployhq/deploy-agent on GitHub
Reconnection : Automatic — runs as a background service

Buddy Proxy Agent: SSH Tunnels Under the Hood

The Buddy Proxy Agent establishes an outbound SSH connection to Buddy's infrastructure and keeps a reverse SSH tunnel alive. Buddy routes deployment traffic back through this tunnel to reach servers inside the private network.

flowchart LR
    A[BuddyAgent] -->|SSH tunnel| B[Buddy]
    B -->|SSH/SFTP only| A
    A -->|SSH/SFTP| C[Server1]
    A -->|SSH/SFTP| D[Server2]
    style A fill:#9b59b6,color:#fff

Like DeployHQ's agent, Buddy's agent acts as a proxy — one agent can route traffic to multiple internal servers. You configure target servers as SFTP or SSH targets within Buddy, selecting the agent as the proxy during setup.

Key technical details:

Tunnel protocol : SSH (reverse tunnel)
Deployment protocols : SSH and SFTP only — no FTP or S3 support
Agent-to-server ratio : One agent, many servers (proxy model)
Runtime : Docker-based agent
Platforms : Linux (Docker required)
Open source : No
Reconnection : Automatic while agent container is running

Octopus Deploy Polling Tentacle: Agent Per Machine

The Octopus Polling Tentacle takes a fundamentally different approach. Instead of one proxy for the network, you install a Tentacle on every deployment target. Each Tentacle independently polls the Octopus Server over HTTPS (port 443 or 10943) asking for work.

flowchart LR
    A[Tentacle1] -->|HTTPS poll| B[OctopusServer]
    C[Tentacle2] -->|HTTPS poll| B
    D[Tentacle3] -->|HTTPS poll| B
    style A fill:#e67e22,color:#fff
    style C fill:#e67e22,color:#fff
    style D fill:#e67e22,color:#fff

When the Octopus Server has a deployment task for a target, it responds to the next poll with the deployment package and instructions. The Tentacle executes the deployment steps locally — no traffic proxying involved.

Key technical details:

Tunnel protocol : HTTPS polling (port 443 or 10943 outbound), WebSocket option available
Deployment protocols : Custom Octopus protocol (Halibut) — packages are pushed to the Tentacle, which executes deployment steps locally
Agent-to-server ratio : One Tentacle per server (per-machine model)
Runtime : .NET
Platforms : Windows, Linux, Docker containers
Open source : Tentacle is open source; Octopus Server is not
Authentication : Certificate-based mutual TLS
Reconnection : Automatic polling on configurable interval

Side-by-Side Comparison

	DeployHQ Agent	Buddy Proxy Agent	Octopus Polling Tentacle
Architecture	Proxy (one agent, many servers)	Proxy (one agent, many servers)	Per-machine (one Tentacle per server)
Tunnel protocol	TLS (TCP 7777)	SSH (reverse tunnel)	HTTPS polling (443/10943)
Deployment protocols	FTP, SFTP, SSH, S3	SSH, SFTP only	Custom (Halibut)
Multi-server access	Yes — CIDR-based ACL	Yes — configure per target	N/A — one per machine
Agents to manage	1 per network	1 per network	1 per server
Runtime requirement	Ruby 2.2+	Docker	.NET
Platforms	Linux, macOS, Windows	Linux (Docker)	Windows, Linux, Docker
Open source	Yes	No	Tentacle only
Authentication	API token	SSH key	Mutual TLS certificates
Inbound ports needed	None	None	None
WebSocket support	No	No	Yes (Windows)
Setup time	~5 minutes	~10 minutes	~15 minutes per server

The Proxy Model vs the Per-Machine Model

This is the most important architectural difference and it affects everything from setup time to security posture.

Proxy Model (DeployHQ, Buddy)

One agent sits at the edge of your private network and proxies deployment traffic to internal servers. You install and manage one process. Adding a new server means updating a config file (DeployHQ) or adding a target in the UI (Buddy) — no software installed on the target server itself.

Advantages:

Minimal infrastructure overhead — one process to monitor and maintain
Adding or removing servers does not require installing or uninstalling agents
The agent machine is the only one that needs outbound internet access

Trade-offs:

Single point of failure — if the agent goes down, all deployments to that network stop
The agent machine has network access to every whitelisted server, which means compromising it could allow lateral movement
Deployment protocols are limited to what the platform supports through the tunnel

Per-Machine Model (Octopus)

Every deployment target runs its own agent. Each one independently connects to the Octopus Server and executes deployments locally.

Advantages:

No single point of failure — one Tentacle going down only affects that server
Each Tentacle can have independent security policies, update schedules, and permissions
Deployments execute locally on the target, so no file transfer protocol limitations
Better fit for environments where different teams own different servers

Trade-offs:

More infrastructure to manage — N servers means N agents to install, monitor, patch, and update
Every target server needs outbound internet access (or access to a shared Octopus Server)
Adding a new deployment target means installing and configuring a new Tentacle

Which Model Fits?

The proxy model is simpler for small to medium deployments where one team manages a cluster of servers behind a single firewall. The per-machine model makes more sense in enterprise environments with dozens of servers, multiple teams, and compliance requirements that demand per-target audit trails.

Protocol Support

This is where DeployHQ's agent stands out.

Many legacy applications and hosting environments rely on FTP or SFTP for deployments — shared hosting with cPanel, older WordPress setups, and environments where SSH access is not available. Buddy's agent only supports SSH and SFTP, which means you cannot deploy to FTP-only servers through the proxy.

DeployHQ's agent proxies at the network level, supporting FTP, SFTP, SSH, and S3 through the same tunnel. This makes it the only option for teams that need to deploy to a mix of modern and legacy infrastructure behind the same firewall.

Octopus takes a different approach entirely — the Tentacle does not proxy protocols. Instead, Octopus sends deployment packages to the Tentacle, which executes deployment steps locally. This means protocol support is not a factor because files never transfer through a tunnel in the traditional sense.

Security Comparison

All three tools avoid inbound firewall rules, but their security models differ:

DeployHQ Agent : Outbound TLS on a single port (7777). The access control file explicitly whitelists which internal servers the agent can reach, limiting blast radius if the agent machine is compromised. The agent source code is fully auditable on GitHub.

Buddy Proxy Agent : Outbound SSH tunnel. SSH provides strong encryption, but the agent is not open source, so you cannot audit what runs inside the container. Access control is managed through Buddy's UI rather than a local config file.

Octopus Polling Tentacle : Outbound HTTPS with certificate-based mutual TLS authentication. This is the strongest authentication model of the three — both the server and the Tentacle verify each other's identity via certificates. However, each Tentacle has full local access to its host machine, and the .NET runtime has a larger attack surface than a Ruby gem or Docker container.

Security Factor	DeployHQ	Buddy	Octopus
Encryption	TLS	SSH	HTTPS/TLS
Authentication	API token	SSH key	Mutual TLS certificates
Access control	Local file (IP/CIDR)	Platform UI	Per-Tentacle certificates
Open source agent	Yes	No	Tentacle only
Attack surface	Ruby gem	Docker container	.NET runtime
Blast radius if compromised	All whitelisted servers	All configured targets	Single server only

Pricing

Deployment agents are typically bundled with the platform, but the platforms themselves have very different pricing models.

DeployHQ

Pricing is based on projects and servers. The Agent is included on all plans, including the free tier.

Plan	Price	Projects	Servers
Free	€0/mo	1	5
Solo	€9/mo	3	15+
Pro	€19/mo	10	50+
Business	€39/mo	20	100+
Enterprise	€99/mo	50+	250+

DeployHQ is a dedicated deployment tool — it does one thing (deploy code from Git) and the pricing reflects that simplicity.

Buddy

Pricing is based on seats and compute minutes. Agents are included, but Buddy is a full CI/CD platform, so you are paying for build pipelines, testing, and deployment together.

Plan	Price	Seats	Key Limits
Free	€0/mo	1	300 GB-minutes, 1 concurrent pipeline
Pro	€29/mo	2	3,000 GB-minutes
Hyper	€99/mo	5	6,000 GB-minutes, SSO

Additional seats cost €9-29/month depending on the plan.

Octopus Deploy

Pricing is based on projects, with add-ons for machines and tenants. Octopus is an enterprise release management platform — significantly more expensive than the other two.

Plan	Price	Projects	Machines
Free	$0/yr	10	10
Professional (Cloud)	$4,330/yr	100	10 (add-ons: $770/yr per 10)
Enterprise (Cloud)	$24,600/yr	100+	Custom

Each Polling Tentacle counts as a machine. Since you need one per server, costs scale linearly with your infrastructure.

Cost for a Typical Setup

For a team deploying to 10 servers behind a firewall:

	DeployHQ	Buddy	Octopus
Monthly cost	€19 (Pro)	€29+ (Pro)	~$361 (Professional)
Agents to install	1	1	10
Includes	Deployment only	Full CI/CD	Release management

When to Use Each Tool

Choose DeployHQ Agent When:

You need to deploy to servers using FTP, SFTP, SSH, or S3 — especially mixed-protocol environments
You want a single agent proxying to multiple servers with minimal infrastructure overhead
You prefer an open source agent you can audit
You use a separate CI/CD tool (GitHub Actions, GitLab CI, Jenkins) and need a dedicated deployment step
Budget matters — it is the most affordable option for deployment-only use cases
You deploy to shared hosting, cPanel, or legacy infrastructure alongside modern servers

Choose Buddy Proxy Agent When:

You want CI/CD and deployment in one platform
All your servers support SSH or SFTP (no FTP-only targets)
You need build pipelines running alongside deployment
Your team is already using Buddy for other CI/CD workflows

Choose Octopus Deploy Polling Tentacle When:

You need per-server agent isolation for compliance or multi-team environments
You are deploying .NET applications on Windows infrastructure
You need enterprise release management features (approvals, tenanted deployments, runbooks)
You have the budget and team to manage Tentacles across many servers
Auditing requirements mandate per-target deployment logs and certificate-based authentication

Conclusion

All three tools solve the same problem — getting deployments through a firewall without opening inbound ports — but they target different audiences:

DeployHQ is the simplest path for teams that need protocol-flexible deployments with minimal infrastructure overhead
Buddy bundles deployment with CI/CD for teams that want everything in one platform
Octopus Deploy is enterprise release management for large-scale Windows/.NET environments

If you are just trying to deploy code to a few servers behind a firewall, the DeployHQ Agent is the fastest way to get there. Install one agent, whitelist your servers, and deploy — same workflow as any publicly accessible server.

Get started with DeployHQ — the Agent is available on all plans, including the free tier. For setup instructions, see the Agent documentation.

Questions about deploying to firewalled servers? Reach out at support@deployhq.com or on Twitter/X.

How to Automate WordPress Deployments with Git (No More FTP)

DeployHQ — Mon, 02 Mar 2026 10:23:04 +0000

If you're still deploying WordPress changes over FTP, you're one accidental overwrite away from a bad day. Manual file transfers don't track what changed, can't be rolled back, and fall apart the moment a second developer touches the project. The fix isn't complicated: put your WordPress theme and plugin code in Git, and let a deployment tool handle the rest.

This guide walks through setting up automated Git-based deployments for WordPress — from structuring your repository to pushing changes to production with zero manual intervention.

Why FTP Deployments Break Down

FTP served WordPress well in 2010. In 2026, it's a liability:

No change history. You can't answer what changed last Tuesday? when something breaks.
No rollback. If a deployment introduces a bug, the only option is to re-upload the previous files — assuming you still have them.
No collaboration. Two developers editing the same theme via FTP will overwrite each other's work.
No automation. Every deployment requires a human clicking through FileZilla. That human will eventually drag the wrong folder.
No staging environment. You're deploying directly to production and hoping for the best.

Git-based deployments solve all five problems. Your code lives in a repository, every change is tracked, and deployments happen automatically when you push.

What to Track in Git (And What to Ignore)

Not everything in a WordPress installation belongs in version control. The general rule: track code you write, ignore everything you install or generate.

Recommended `.gitignore` for WordPress

# WordPress core — don't track, install via wp-cli or composer
/wp-admin/
/wp-includes/
/wp-*.php
/index.php
/license.txt
/readme.html
/xmlrpc.php

# wp-content: track selectively
/wp-content/uploads/
/wp-content/upgrade/
/wp-content/cache/
/wp-content/advanced-cache.php
/wp-content/object-cache.php
/wp-content/db.php

# Environment and secrets
.env
wp-config-local.php
*.sql
*.sql.gz

# Dependencies
/vendor/
/node_modules/

# OS files
.DS_Store
Thumbs.db

What You Should Track

wp-content/
├── themes/
│ └── your-custom-theme/ ← Track this
├── plugins/
│ └── your-custom-plugin/ ← Track this
└── mu-plugins/ ← Track this (must-use plugins)

If you use third-party plugins, manage them with Composer and track only the composer.json and composer.lock files — not the plugin source code itself.

Setting Up Git for WordPress

Option A: Track Only Your Theme/Plugin

The simplest approach — your Git repo contains only the code you write:

cd /path/to/your-theme
git init
git add .
git commit -m "Initial commit of theme"
git remote add origin git@github.com:yourteam/your-wp-theme.git
git push -u origin main

DeployHQ then deploys this repo to /var/www/html/wp-content/themes/your-theme/ on your server.

Option B: Track the Entire wp-content Directory

For projects where you manage multiple themes, plugins, and mu-plugins:

cd /path/to/wordpress/wp-content
git init
# Add your .gitignore first
git add .gitignore
git add themes/your-theme/ plugins/your-plugin/ mu-plugins/
git commit -m "Initial wp-content structure"

Option C: Full WordPress via Composer (Recommended for Teams)

Use Roots Bedrock or a Composer-based WordPress setup for the most professional workflow:

composer create-project roots/bedrock your-project
cd your-project
git init && git add . && git commit -m "Initial Bedrock setup"

Bedrock gives you:

WordPress core managed via Composer (not tracked in Git)
.env file for environment-specific configuration
Better directory structure separating web root from application code
Plugin management via composer require wpackagist-plugin/plugin-name

Method 1: Automated Deployments with DeployHQ

DeployHQ connects your Git repository to your server and deploys automatically on every push. No scripts to write, no CI pipeline to maintain.

Step 1: Create a Project

In your DeployHQ dashboard, create a new project and connect your GitHub, GitLab, or Bitbucket repository.

Step 2: Add Your Server

Add your production server using SSH (SFTP also works but SSH is faster and more reliable):

Protocol: SSH/SFTP
Hostname: your server IP or domain
Username: your deploy user (don't use root)
Authentication: SSH key (DeployHQ generates one — add the public key to your server's ~/.ssh/authorized_keys)
Deployment path: the target directory on your server, e.g.:
- Theme only: /var/www/html/wp-content/themes/your-theme
- Full wp-content: /var/www/html/wp-content
- Bedrock: /var/www/html/current

Step 3: Configure Build Steps

Build steps run on DeployHQ's servers before files are transferred. Use them for:

Install dependencies:

composer install --no-dev --optimize-autoloader
npm ci && npm run build

Compile assets:

# If your theme uses Webpack, Vite, or similar
npm run production

Step 4: Add Post-Deployment SSH Commands

After files are transferred, run commands on your server:

# Clear WordPress object cache
wp cache flush --path=/var/www/html

# Clear OPcache (if using PHP-FPM)
sudo systemctl reload php8.3-fpm

# Run database migrations (if using a migration plugin)
wp core update-db --path=/var/www/html

# Clear CDN cache (example: Cloudflare)
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer CF_TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"purge_everything":true}'

Step 5: Enable Automatic Deployments

In your project settings, enable the webhook. DeployHQ will deploy automatically every time you push to the configured branch. You can also set up different branches for different servers:

main → Production server
staging → Staging server
develop → Development server

Step 6: Use .deployignore

Create a .deployignore file in your repo root to exclude files that shouldn't be transferred to the server:

# Development files
node_modules/
tests/
.github/
.gitignore
README.md
package.json
package-lock.json
phpcs.xml
phpunit.xml

# Source files (only deploy compiled assets)
src/scss/
src/js/
webpack.config.js
vite.config.js

This keeps your deployment lean — only production-ready files reach the server.

Method 2: GitHub Actions + SSH

For teams that want everything in their CI pipeline without a separate deployment tool:

name: Deploy WordPress Theme
on:
  push:
    branches: [main]

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

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - name: Build assets
        run: |
          npm ci
          npm run build

      - name: Deploy via rsync
        uses: burnett01/rsync-deployments@7.0.1
        with:
          switches: -avz --delete --exclude='.git' --exclude='node_modules' --exclude='src/'
          path: ./
          remote_path: /var/www/html/wp-content/themes/your-theme/
          remote_host: ${{ secrets.SSH_HOST }}
          remote_user: ${{ secrets.SSH_USER }}
          remote_key: ${{ secrets.SSH_PRIVATE_KEY }}

      - name: Post-deployment commands
        uses: appleboy/ssh-action@v1
        with:
          host: ${{ secrets.SSH_HOST }}
          username: ${{ secrets.SSH_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            wp cache flush --path=/var/www/html
            sudo systemctl reload php8.3-fpm

This works, but you're maintaining the pipeline yourself. When something breaks at 2am, you're debugging YAML instead of deploying a fix. DeployHQ handles this infrastructure for you.

Method 3: WP-CLI Deployment Scripts

For power users who want full control via command-line scripts:

#!/bin/bash
set -euo pipefail

SERVER="deploy@your-server.com"
DEPLOY_PATH="/var/www/html/wp-content/themes/your-theme"
BRANCH="main"

echo "=== Deploying WordPress theme ==="

# Pre-flight checks
ssh $SERVER "test -d $DEPLOY_PATH" || { echo "Deploy path missing"; exit 1; }

# Build locally
npm ci && npm run build

# Sync files (excluding dev files)
rsync -avz --delete \
  --exclude='.git' \
  --exclude='node_modules' \
  --exclude='src/' \
  --exclude='tests/' \
  ./ $SERVER:$DEPLOY_PATH/

# Post-deploy
ssh $SERVER "wp cache flush --path=/var/www/html && sudo systemctl reload php8.3-fpm"

echo "=== Deployment complete ==="

Simple, transparent, and portable. But it runs on your machine, so it doesn't work when you're offline, and other team members can't deploy without access to this script.

Handling the Hard Part: Database Migrations

WordPress doesn't have a built-in migration system like Rails or Laravel. Deploying code changes that require database schema updates needs careful handling.

Strategy 1: WP-CLI for Core Updates

# After deploying new WordPress core files
wp core update-db --path=/var/www/html

Strategy 2: Migration Plugins

Plugins like WP Migrate handle database syncing between environments. Run after code deployment to push schema changes.

Strategy 3: Custom Migration Scripts

For custom plugins that modify the database, use WordPress's dbDelta() function in your plugin activation hook, or run WP-CLI commands post-deployment:

wp eval 'your_plugin_run_migrations();' --path=/var/www/html

What NOT to Do

Never copy the production database to staging and then deploy staging code back to production. Data flows down (production → staging), code flows up (staging → production).

Multi-Environment Setup

A professional WordPress workflow uses at least three environments:

flowchart LR
    A[Local] -->|git push| B[Git Repository]
    B -->|auto-deploy| C[Staging]
    C -->|manual promote| D[Production]

In DeployHQ

Create two servers in the same project:

Server	Branch	Deploy Mode
Staging	`staging`	Automatic on push
Production	`main`	Manual (one-click) or automatic

This gives you a safety net: code deploys to staging first, you verify it works, then merge to main to push to production.

WordPress Configuration Per Environment

Use wp-config.php with environment detection, or better yet, use a .env file (native with Bedrock):

// wp-config.php approach
$env = getenv('WP_ENV') ?: 'production';

if ($env === 'staging') {
    define('WP_DEBUG', true);
    define('WP_DEBUG_LOG', true);
    define('DISALLOW_FILE_MODS', true);
}

WordPress-Specific .deployignore Patterns

Beyond the basics, these WordPress-specific exclusions keep your deployments clean:

# WordPress dev/test files
tests/
phpunit.xml.dist
phpcs.xml.dist
.phpcs.xml

# Theme development
src/scss/
src/js/
webpack.config.js
vite.config.js
tailwind.config.js
postcss.config.js
babel.config.js

# Documentation
*.md
LICENSE
CHANGELOG

# CI/CD config (handled by DeployHQ, not needed on server)
.github/
.gitlab-ci.yml
bitbucket-pipelines.yml

Common Mistakes to Avoid

Tracking wp-config.php in Git. This file contains database passwords. Use .env files or environment-specific config files that are in .gitignore.

Deploying node_modules. Your build step should compile assets. Only deploy the compiled CSS/JS, never the 200MB of npm packages.

Using root for SSH deployments. Create a dedicated deploy user with limited permissions. It should own the web directory and nothing else.

Skipping staging. It works on my machine is not a deployment strategy. Always verify on staging first.

Forgetting to flush cache. WordPress aggressively caches everything. A deployment without a cache clear means users see stale content.

When to Use Each Method

Factor	DeployHQ	GitHub Actions	WP-CLI Script
Setup time	10 minutes	1-2 hours	30 minutes
Maintenance	None (managed)	You maintain YAML	You maintain script
Rollback	One-click	Manual revert	Manual revert
Multi-server	Built-in	DIY per environment	DIY per server
Team access	Web dashboard	Repo access required	CLI access required
Build steps	Built-in	GitHub-hosted runners	Your machine
Cost	Free tier available	Free for public repos	Free
Best for	Teams, agencies, multiple sites	Dev teams already using GH Actions	Solo devs, simple setups

Get Started

The fastest path from FTP to automated deployments:

Put your theme/plugin code in Git (10 minutes)
Create a free DeployHQ project (5 minutes)
Connect your repo and add your server (5 minutes)
Push a change and watch it deploy automatically

That's it. No YAML to debug, no scripts to maintain, no FTP clients to open. Your WordPress deployments now work like every other modern web project.

If you run into issues, reach out to our team at support@deployhq.com or find us on Twitter/X.