DEV Community: DeployHQ

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.

AI Code Review as Your Last Line of Defense Before Deployment

DeployHQ — Fri, 27 Feb 2026 15:44:24 +0000

Catching security vulnerabilities, performance issues, and misconfigurations before code reaches production.

Code review is one of the most valuable practices in software development. A second pair of eyes catches bugs, improves code quality, and spreads knowledge across the team. But traditional code review has limitations: reviewers get tired, miss edge cases, and can't possibly remember every security best practice.

What if you had a reviewer who never got tired, had encyclopedic knowledge of security vulnerabilities, and could analyse every line of every commit before it reached production?

AI-powered code review is becoming that reviewer—and it's emerging as a critical last line of defense in the deployment pipeline. This is part of the broader shift toward AI-integrated deployment workflows that's transforming how we ship code.

The Gap in Traditional Code Review

Human code reviewers are excellent at many things: evaluating architecture decisions, ensuring code readability, and mentoring junior developers. But they're not ideal for everything:

Human Reviewers Excel At	Human Reviewers Miss
Architecture decisions	Subtle security vulnerabilities
Code readability	Dependency vulnerabilities
Business logic correctness	Performance regressions
Mentoring and teaching	Configuration drift
Context and intent	Consistent enforcement

A human reviewer might catch that a function is poorly named. They're less likely to notice that a dependency was updated to a version with a known security vulnerability, or that a new SQL query is vulnerable to injection in an edge case.

flowchart TD
    subgraph Traditional
        A[Write Code] --> B[Human Review]
        B --> C[Deploy]
        C --> D[Discover Issues in Production]
    end

    subgraph AI-Augmented
        E[Write Code] --> F[Human Review]
        F --> G[AI Security/Performance Review]
        G --> H[Deploy]
        H --> I[Fewer Production Issues]
    end

    style A fill:#64748B,color:#fff
    style B fill:#64748B,color:#fff
    style C fill:#64748B,color:#fff
    style D fill:#EF4444,color:#fff
    style E fill:#64748B,color:#fff
    style F fill:#64748B,color:#fff
    style G fill:#0891B2,color:#fff
    style H fill:#64748B,color:#fff
    style I fill:#10B981,color:#fff

Want to catch issues earlier? DeployHQ's build pipelines can run tests, linters, and security scans before deployment—stopping bad code before it reaches your servers.

What AI Code Review Catches

AI code review is particularly effective at catching issues that require pattern matching across large codebases or knowledge of external factors:

1. Security Vulnerabilities

AI can identify common vulnerability patterns that humans might overlook:

# AI would flag this SQL injection vulnerability
def search_users(query)
  User.where("name LIKE '%#{query}%'") # VULNERABLE: SQL Injection risk
end

# AI suggests this fix
def search_users(query)
  User.where("name LIKE ?", "%#{query}%") # SAFE: Parameterised query
end

Common security issues AI catches:

Vulnerability Type	Example	Why AI Catches It
SQL Injection	String interpolation in queries	Pattern matching
XSS	Unescaped user input in templates	Output context analysis
Hardcoded Secrets	API keys in code	Pattern recognition
Insecure Dependencies	Known CVEs in packages	Database lookup
Auth Bypass	Missing authentication checks	Control flow analysis

2. Performance Regressions

AI can spot code patterns that will cause performance issues at scale:

# AI would flag this N+1 query
def dashboard
  @posts = Post.all
  # In the view: @posts.each { |p| p.author.name }
  # PROBLEM: This will execute 1 + N queries
end

# AI suggests eager loading
def dashboard
  @posts = Post.includes(:author).all # FIXED: Single query with JOIN
end

3. Configuration Issues

Before deployment, AI can verify that all required configuration is in place:

# AI reviews deployment config and catches:

# WARNING: Missing in production but present in staging
environment_variables:
  staging:
    - DATABASE_URL
    - REDIS_URL
    - STRIPE_SECRET_KEY
    - NEW_RELIC_LICENSE # Present in staging
  production:
    - DATABASE_URL
    - REDIS_URL
    - STRIPE_SECRET_KEY
    # NEW_RELIC_LICENSE missing! AI flags this

Environment variable management made easy: DeployHQ's environment variables let you manage secrets securely across all your environments from one dashboard.

4. Breaking Changes

AI can analyse API changes and flag potential breaking changes:

# Previous version
def create_order(user_id:, items:)
  # ...
end

# New version - AI flags breaking change
def create_order(user_id:, items:, shipping_address:) # WARNING: New required param
  # ...
end

# AI suggests backward compatibility
def create_order(user_id:, items:, shipping_address: nil) # SAFE: Optional param
  # ...
end

Integrating AI Review into Your Deployment Pipeline

AI code review works best when integrated directly into your deployment workflow. Here's how to structure it:

flowchart LR
    A[Push to Branch] --> B[CI Tests]
    B --> C[Human PR Review]
    C --> D[AI Security Review]
    D --> E{Issues Found?}
    E -->|Yes| F[Block + Report]
    E -->|No| G[Deploy to Staging]
    G --> H[AI Production Readiness Check]
    H --> I[Deploy to Production]

    style A fill:#64748B,color:#fff
    style B fill:#64748B,color:#fff
    style C fill:#64748B,color:#fff
    style D fill:#0891B2,color:#fff
    style E fill:#F59E0B,color:#fff
    style F fill:#EF4444,color:#fff
    style G fill:#10B981,color:#fff
    style H fill:#0891B2,color:#fff
    style I fill:#10B981,color:#fff

DeployHQ's build commands can run at each stage—executing security scans, running tests, and blocking deployments that don't pass.

Pre-Deployment Checklist: AI Edition

Configure your AI review to check for these categories before each deployment:

ai_review_config:
  security:
    - sql_injection
    - xss_vulnerabilities
    - hardcoded_secrets
    - insecure_dependencies
    - authentication_bypass
    - authorization_issues

  performance:
    - n_plus_one_queries
    - missing_indexes
    - memory_leaks
    - inefficient_loops
    - large_payload_responses

  reliability:
    - error_handling
    - null_pointer_risks
    - race_conditions
    - resource_cleanup

  configuration:
    - missing_env_vars
    - config_drift_between_environments
    - deprecated_settings

  compatibility:
    - breaking_api_changes
    - database_migration_risks
    - dependency_conflicts

Practical Implementation

Here's how to implement AI code review in your workflow today:

Using AI Assistants for Manual Review

Before deploying, you can ask an AI assistant to review your changes:

**Prompt for Pre-Deployment Review:**

Review the following code changes for security vulnerabilities, 
performance issues, and potential bugs. Focus on:

1. SQL injection or XSS vulnerabilities
2. N+1 queries or performance regressions  
3. Missing error handling
4. Breaking API changes
5. Security best practices

Changes:
[PASTE DIFF OR CODE HERE]

For each issue found, provide:
- Severity (Critical/High/Medium/Low)
- Location (file and line)
- Description of the issue
- Recommended fix with code example

Sample AI Review Output

## AI Code Review Results

### Critical Issues (1)

**SQL Injection Vulnerability**
- File: `app/models/search.rb`, line 23
- Issue: User input directly interpolated into SQL query
- Fix:

ruby
# Before (vulnerable)
where("title LIKE '%#{params[:q]}%'")

# After (safe)
where("title LIKE ?", "%#{sanitize_sql_like(params[:q])}%")


### Medium Issues (2)

**N+1 Query**

- File: `app/controllers/posts_controller.rb`, line 45
- Issue: Loading comments without eager loading
- Impact: ~50ms additional latency per post
- Fix: Add `.includes(:comments)` to the query

**Missing Error Handling**

- File: `app/services/payment_processor.rb`, line 78
- Issue: External API call without rescue block
- Fix: Wrap in begin/rescue and handle timeout/connection errors

### Suggestions (1)

**Consider Adding Index**

- File: `db/migrate/20240115_add_status_to_orders.rb`
- Suggestion: The `status` column is queried frequently. Consider adding an index for better performance.

* * *

**Summary:** 1 critical issue must be fixed before deployment.

ruby

When issues are found post-deployment, AI-powered troubleshooting can help you quickly identify the root cause and fix it.

Building Automated AI Gates

For teams ready to automate, here's a pattern for implementing AI review gates:

# Example: Pre-deployment AI review hook

class DeploymentReview
  SEVERITY_THRESHOLDS = {
    staging: :high, # Block on high+ severity
    production: :medium # Block on medium+ severity
  }

  def self.check(environment:, changes:)
    results = AIReviewer.analyse(changes)

    threshold = SEVERITY_THRESHOLDS[environment]
    blocking_issues = results.issues.select do |issue|
      issue.severity >= threshold
    end

    if blocking_issues.any?
      {
        status: :blocked,
        reason: "#{blocking_issues.count} issues require attention",
        issues: blocking_issues,
        report_url: results.full_report_url
      }
    else
      {
        status: :approved,
        warnings: results.issues.select { |i| i.severity < threshold },
        report_url: results.full_report_url
      }
    end
  end
end

Automate your quality gates: DeployHQ's deployment conditions can block deployments when tests fail or when specific files change—add AI review as another gate in your pipeline.

What AI Review Doesn't Replace

AI code review is powerful, but it complements rather than replaces other practices:

Still Need Humans For	AI Handles Well
Architecture decisions	Pattern-based vulnerabilities
Business logic review	Dependency security
Code style preferences	Consistent rule enforcement
Mentoring developers	Exhaustive coverage
Context-dependent decisions	Known vulnerability databases

The ideal setup uses both: human reviewers for high-level decisions and AI reviewers for systematic, exhaustive checks.

flowchart TB
    subgraph HumanReview
        H1[Architecture]
        H2[Business Logic]
        H3[Readability]
        H4[Mentoring]
    end

    subgraph AIReview
        A1[Security Patterns]
        A2[Performance Issues]
        A3[Dependency Risks]
        A4[Configuration Gaps]
    end

    subgraph Both
        B1[Critical Business Logic]
        B2[Complex Security Decisions]
    end

    style H1 fill:#64748B,color:#fff
    style H2 fill:#64748B,color:#fff
    style H3 fill:#64748B,color:#fff
    style H4 fill:#64748B,color:#fff
    style A1 fill:#0891B2,color:#fff
    style A2 fill:#0891B2,color:#fff
    style A3 fill:#0891B2,color:#fff
    style A4 fill:#0891B2,color:#fff
    style B1 fill:#10B981,color:#fff
    style B2 fill:#10B981,color:#fff

Measuring AI Review Effectiveness

Track these metrics to measure the value of AI code review:

Metric	What to Track	Why It Matters
Issues Caught Pre-Production	Security vulns, perf issues, config gaps	Direct prevention value
Production Incident Reduction	Before/after AI implementation	Business impact
False Positive Rate	AI flags that weren't real issues	Review efficiency
Time to Deploy	PR merge to production	Pipeline speed

Getting Started Today

You don't need sophisticated tooling to start with AI code review. Here's a progression:

Week 1: Manual AI Reviews

Before each deployment, paste your diff into an AI assistant with the review prompt above. Track what it finds.

Month 1: Standardised Process

Create a checklist that includes AI review. Document the prompts your team uses. Start tracking metrics.

Month 3: Automated Integration

Integrate AI review into your CI/CD pipeline. Set up automated blocking rules. Create dashboards for tracking.

Looking ahead, this AI review will integrate with conversational deployment—you'll just say deploy if the AI review passes and it'll happen automatically.

Key Takeaways

AI code review is becoming an essential part of the deployment pipeline—a tireless reviewer that catches what humans miss. Here's what to remember:

AI excels at pattern-based security checks, performance analysis, and configuration verification
Human reviewers remain essential for architecture, business logic, and mentoring
Start with manual AI reviews before automating
Configure severity thresholds differently for staging vs production
Track metrics to measure effectiveness and identify gaps

The question isn't whether to add AI to your code review process—it's how quickly you can implement it before your next production incident.

Continue Reading

How AI Coding Assistants Are Changing Deployments — The big picture
AI-Powered Deployment Troubleshooting — When issues slip through
The Rise of Conversational Deployments — Deploy with natural language
MCP and the Future of AI-Integrated DevOps — The technical foundation

Ready to add more safety to your deployments? Start your free DeployHQ trial and configure build pipelines that run tests and scans before every deployment.

Have ideas for AI deployment features? Tell us on X — we'd love to hear what you'd build.

OpenTelemetry in Practice: Setting Up Metrics, Traces, and Logs for Your Applications

DeployHQ — Wed, 25 Feb 2026 17:40:18 +0000

Your deployment pipeline is green, the health check returns 200, and users are reporting that the site is slow. You check the server — CPU is fine, memory is fine, disk is fine. So where's the problem?

This is the observability gap. Most teams have some logging, maybe a dashboard showing CPU and memory, but no coherent way to answer the question that actually matters during an incident: what is happening, right now, across all the services involved in this request?

OpenTelemetry has become the industry standard for closing that gap. It's a CNCF project (the second most active after Kubernetes) that provides a single, vendor-neutral framework for collecting metrics, traces, and logs from any application — regardless of language, framework, or infrastructure. This guide covers what OpenTelemetry actually is, how to set it up, and how to connect it to your deployment pipeline so you always know whether the last release caused the problem.

The Three Pillars — and Why You Need All of Them

Observability rests on three signal types, each answering a different question:

Metrics answer is something wrong? They're aggregated numbers — request count, error rate, response time percentiles, CPU usage, queue depth. Metrics are cheap to collect, cheap to store, and the foundation of alerting. When your PagerDuty goes off at 2 AM, it's because a metric crossed a threshold.

Traces answer where is it slow? A distributed trace follows a single request as it moves across services, databases, message queues, and external APIs. Each operation is a span with a start time, duration, and metadata. When a user reports that checkout is slow, traces show you that 800ms of a 1.2s request is spent waiting for the payment gateway.

Logs answer why did it break? Logs provide the detailed context that metrics and traces can't: the exact SQL query that failed, the malformed JSON payload, the specific validation error. The key is correlating logs with traces — when a trace shows a slow span, the correlated logs explain what happened during that span.

Without all three, you're debugging with partial information:

Metrics without traces: you know something is slow, but not where
Traces without logs: you know where it's slow, but not why
Logs without traces: you have detail but can't connect it across services

Why OpenTelemetry Won

Before OpenTelemetry, every observability vendor had its own instrumentation library. If you used Datadog, you installed the Datadog agent. If you used New Relic, you installed their SDK. Switching vendors meant re-instrumenting your entire application.

OpenTelemetry solves this by separating instrumentation (collecting telemetry from your application) from export (sending it to a backend). You instrument once with OpenTelemetry, then export to whatever backend you choose — Grafana, Datadog, New Relic, Honeycomb, Jaeger, or any combination. Switch backends without changing a line of application code.

The project provides:

Language SDKs for most major languages (Python, JavaScript/Node.js, Java, Go, .NET, Ruby, PHP, Rust)
Auto-instrumentation agents that instrument popular libraries without code changes
The OpenTelemetry Collector — a proxy that receives, processes, and exports telemetry data
Semantic conventions — standardised attribute names so http.request.method means the same thing everywhere

Getting Started: The Two Approaches

Zero-Code Auto-Instrumentation

The fastest way to start is auto-instrumentation — agents or libraries that hook into your runtime and automatically instrument HTTP requests, database queries, and other common operations without changing your application code.

Python:

pip install opentelemetry-distro opentelemetry-exporter-otlp
opentelemetry-bootstrap -a install

# Run your app with auto-instrumentation
opentelemetry-instrument \
  --service_name my-app \
  --exporter_otlp_endpoint http://collector:4317 \
  python app.py

This automatically instruments Flask, Django, FastAPI, SQLAlchemy, requests, urllib3, psycopg2, and dozens of other Python libraries.

Node.js:

npm install @opentelemetry/auto-instrumentations-node \
  @opentelemetry/sdk-node @opentelemetry/exporter-trace-otlp-grpc


// tracing.js — require this BEFORE your application
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-grpc');

const sdk = new NodeSDK({
  serviceName: 'my-app',
  traceExporter: new OTLPTraceExporter({
    url: 'http://collector:4317',
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();


node --require ./tracing.js app.js

This instruments Express, Fastify, Koa, pg, mysql2, mongodb, Redis, HTTP client calls, and more.

Java:

# Download the agent JAR
curl -L -o opentelemetry-javaagent.jar \
  https://github.com/open-telemetry/opentelemetry-java-instrumentation/releases/latest/download/opentelemetry-javaagent.jar

# Run with the agent attached
java -javaagent:opentelemetry-javaagent.jar \
  -Dotel.service.name=my-app \
  -Dotel.exporter.otlp.endpoint=http://collector:4317 \
  -jar app.jar

The Java agent supports over 100 libraries — Spring, Quarkus, JDBC, Hibernate, Kafka, gRPC, and more. It uses bytecode manipulation, so no code changes are needed at all.

What auto-instrumentation costs: typically 2-5% runtime overhead and 5-15% on startup time. For most applications, this is negligible. For latency-critical hot paths, you can selectively disable specific instrumentations.

Manual SDK Instrumentation

Auto-instrumentation covers infrastructure operations (HTTP, databases, messaging) but can't instrument your business logic. If you want to trace calculate shipping cost or count orders placed per minute, you need the SDK.

Python example:

from opentelemetry import trace, metrics

tracer = trace.get_tracer("order-service")
meter = metrics.get_meter("order-service")
orders_counter = meter.create_counter("orders.placed", description="Total orders placed")

def place_order(request):
    with tracer.start_as_current_span("place_order") as span:
        span.set_attribute("order.items", len(request.items))
        span.set_attribute("order.customer_id", request.customer_id)

        try:
            order = process_order(request)
            orders_counter.add(1)
            span.set_attribute("order.id", order.id)
            return order
        except Exception as e:
            span.record_exception(e)
            span.set_status(trace.StatusCode.ERROR, str(e))
            raise

Node.js example:

const { trace, metrics } = require('@opentelemetry/api');

const tracer = trace.getTracer('order-service');
const meter = metrics.getMeter('order-service');
const ordersCounter = meter.createCounter('orders.placed');

async function placeOrder(request) {
  return tracer.startActiveSpan('place_order', async (span) => {
    span.setAttribute('order.items', request.items.length);
    span.setAttribute('order.customer_id', request.customerId);

    try {
      const order = await processOrder(request);
      ordersCounter.add(1);
      span.setAttribute('order.id', order.id);
      return order;
    } catch (error) {
      span.recordException(error);
      span.setStatus({ code: trace.SpanStatusCode.ERROR, message: error.message });
      throw error;
    } finally {
      span.end();
    }
  });
}

Auto-instrumentation and manual instrumentation work together seamlessly. The auto-instrumented spans (HTTP, database) and your custom business spans are linked into the same trace automatically.

The Collector: Your Telemetry Router

The OpenTelemetry Collector is a proxy that sits between your applications and your observability backend. Applications send telemetry to the collector, and the collector routes it to whichever backends you use.

# otel-collector-config.yaml
receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  batch:
    timeout: 5s
    send_batch_size: 1024

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  otlp/traces:
    endpoint: tempo:4317
    tls:
      insecure: true
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp/traces]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]

Why not export directly from your application? Three reasons:

Decoupling. Your applications don't need to know about your observability backend. Switch from Jaeger to Grafana Tempo? Change the collector config, not your application code.
Processing. The collector can sample, filter, enrich, and batch telemetry before forwarding — reducing storage costs and noise.
Reliability. The collector buffers data during backend outages. Direct export risks dropping telemetry when the backend is unreachable.

Sampling: Don't Trace Everything in Production

Tracing every request in production generates enormous volumes of data. A service handling 1,000 requests per second produces 86 million traces per day. At approximately 1 KB per span with a 5-span average trace, that's ~430 GB/day.

Head-based sampling decides at the start of a trace whether to record it:

# Environment variable — sample 10% of traces
OTEL_TRACES_SAMPLER=parentbased_traceidratio
OTEL_TRACES_SAMPLER_ARG=0.1

Tail-based sampling (configured in the collector) decides after the trace completes, allowing you to keep all error traces and slow traces while sampling normal traffic:

processors:
  tail_sampling:
    policies:
      - name: errors
        type: status_code
        status_code: { status_codes: [ERROR] }
      - name: slow-traces
        type: latency
        latency: { threshold_ms: 1000 }
      - name: baseline
        type: probabilistic
        probabilistic: { sampling_percentage: 10 }

This keeps 100% of errors and slow requests (the ones you actually need to debug) while sampling 10% of healthy traffic. In practice, this reduces trace storage by 80-90% while preserving diagnostic value.

Connecting Observability to Your Deployment Pipeline

Observability becomes most valuable when it's connected to your deployment pipeline. Correlating deployments with metric changes answers the most common production question: did the last deployment cause this?

With DeployHQ, you can use post-deployment commands or webhooks to annotate your monitoring dashboards whenever a deployment completes:

# Post-deploy command: annotate Grafana with deployment event
curl -s -X POST http://grafana:3000/api/annotations \
  -H "Authorization: Bearer $GRAFANA_API_KEY" \
  -H "Content-Type: application/json" \
  -d "{
    \"text\": \"Deployed $DEPLOYHQ_REVISION to $DEPLOYHQ_SERVER\",
    \"tags\": [\"deployment\", \"$DEPLOYHQ_PROJECT\"]
  }"

When you see a metric anomaly on a dashboard, the deployment annotation immediately tells you whether it correlates with a release — saving the first 10 minutes of every incident investigation.

For zero-downtime deployments, observability is especially critical. You need to verify that the new version is healthy before the old version is taken down. Health check endpoints should go beyond a simple HTTP 200:

# Flask example — readiness probe that checks dependencies
@app.route('/health/ready')
def readiness():
    checks = {}

    try:
        db.session.execute(text('SELECT 1'))
        checks['database'] = 'ok'
    except Exception as e:
        checks['database'] = f'failed: {e}'
        return jsonify(checks), 503

    try:
        redis_client.ping()
        checks['cache'] = 'ok'
    except Exception as e:
        checks['cache'] = f'failed: {e}'
        return jsonify(checks), 503

    checks['status'] = 'ready'
    return jsonify(checks), 200

A Practical Starting Stack

If you're starting from zero, here's a realistic observability stack that works for small-to-medium deployments without enterprise licensing costs:

Component	Tool	Purpose
Instrumentation	OpenTelemetry SDK + Auto-instrumentation	Collect traces, metrics, logs
Collector	OpenTelemetry Collector	Route and process telemetry
Metrics	Prometheus + Grafana	Metric storage, dashboards, alerting
Traces	Grafana Tempo	Distributed trace storage and search
Logs	Grafana Loki	Log aggregation with trace correlation
Alerting	Grafana Alerting	Threshold-based alerts to Slack/PagerDuty

This entire stack is open source and can run on a single server for small deployments, or scale horizontally as your traffic grows. A Docker Compose setup can have the full stack running in minutes.

For teams that prefer managed solutions, OpenTelemetry exports to Datadog, New Relic, Honeycomb, Grafana Cloud, and AWS CloudWatch without any instrumentation changes — switch exporters in the collector config and you're done.

What to Alert On

The most common mistake with observability is alerting on symptoms instead of causes. CPU at 90% is a symptom. Database connection pool exhausted is a cause. Alert on the metrics closest to the actual problem.

Good alerts:

Error rate exceeds 1% of requests (5-minute rolling window)
P99 response time exceeds 2 seconds
Database connection pool active connections equals max pool size
Queue depth exceeding consumer throughput for >5 minutes

Bad alerts:

CPU above 80% (normal for many workloads)
Any single 500 error (noise — use error rate instead)
Disk usage above 70% (too early, creates alert fatigue)

Essential OpenTelemetry metrics to track:

http.server.request.duration — response time histogram, broken down by route and status code
http.server.active_requests — current in-flight requests (early saturation warning)
db.client.connections.usage — database pool utilization
process.runtime.*.memory — language-specific memory metrics (heap, RSS)

Common Mistakes

Logging too much. Debug-level logging in production generates noise that obscures real signals. Use structured logging (JSON) with severity levels, and keep production at INFO or WARN. Use trace context to find detailed logs when you need them.

Ignoring trace propagation. OpenTelemetry propagates trace context automatically for supported libraries, but custom HTTP clients, manual thread pools, and async operations can break the chain. If your traces end at service boundaries, check that W3C Trace Context headers (traceparent, tracestate) are being forwarded.

Sampling too aggressively too early. Start with 100% sampling in development and staging. Only reduce sampling in production when storage costs justify it — and always keep 100% sampling for errors.

Treating observability as optional. We'll add monitoring later is technical debt that compounds. Instrument from day one, even if it's just the auto-instrumentation agent. The cost of adding it is trivial compared to the cost of debugging a production incident blind.

Not connecting deployments to metrics. Every deployment should be annotated in your monitoring dashboards. Without this correlation, the first 10 minutes of every incident are spent asking did anything change? — a question your CI/CD pipeline already knows the answer to.

Ready to deploy your observable application? DeployHQ handles the build and deployment pipeline while you focus on application quality. Post-deployment hooks make it easy to connect your releases to your monitoring — so you always know what changed and when.

Questions about setting up observability for your services? Reach out at support@deployhq.com or find us on Twitter/X.

The Rise of Conversational Deployments: Will We Deploy with Natural Language?

DeployHQ — Mon, 23 Feb 2026 08:11:46 +0000

The Rise of Conversational Deployments: Will We Deploy with Natural Language?

Exploring the future where deploy to production is a conversation, not a checklist.

Picture this: You've just finished a feature. Instead of navigating to your deployment dashboard, selecting the right project, choosing the branch, configuring options, and clicking deploy, you simply say:

Deploy the user-authentication branch to staging, run the smoke tests, and let me know when it's ready.

And it just happens.

This isn't a far-off fantasy—it's the direction deployment tooling is heading. As we explored in How AI Coding Assistants Are Changing Deployments, the boundary between writing code and shipping code is blurring. In this post, we'll dive deeper into conversational deployments specifically—what's making them possible, and what this means for how developers will ship code in the near future.

From Buttons to Commands to Conversation

The history of deployment interfaces follows a clear progression toward simplicity:

timeline
    title Evolution of Deployment Interfaces
    2000s : Manual FTP uploads
          : SSH and rsync scripts
    2010s : Web dashboards
          : Click-to-deploy buttons
    Mid-2010s : CLI tools
          : Git-based workflows
    2020s : ChatOps
          : Slack/Discord commands
    2025+ : Natural language
          : AI-powered conversation

Each evolution removed friction and made deployments more accessible. FTP required knowing server paths. CLIs required memorising commands. Dashboards simplified this to clicks—but you still needed to know where to click.

Conversational deployments represent the next logical step: you describe what you want in plain language, and the system figures out how to make it happen.

Already want simpler deployments? DeployHQ's automatic deployments trigger when you push to Git—no clicking required. It's the foundation for conversational deployment.

What Makes Conversational Deployments Different

Conversational deployment isn't just voice-activated button clicking. It's a fundamentally different interaction model:

Traditional Deployment	Conversational Deployment
Navigate to dashboard	State your intent
Find the right project	AI identifies context
Select options from menus	AI infers sensible defaults
Click deploy	AI executes and monitors
Watch progress manually	AI reports status proactively
Check logs if something fails	AI explains issues in plain language

The key difference is intent over instruction. You express what you want to achieve, not how to achieve it.

Example Conversations

Simple deployment:

Developer: "Deploy main to production"

AI: "I'll deploy the main branch to production. This includes 
12 commits since the last deployment. The most recent commit 
is 'Add rate limiting to API endpoints' from 2 hours ago.

Starting deployment...
✓ Build completed (1m 23s)
✓ Tests passed (45s)
✓ Deployed to production

Production is now running commit abc123. All health checks 
are passing. Would you like me to monitor for any issues 
over the next 30 minutes?"

Conditional deployment:

Developer: "Deploy to staging, but only if all tests pass and 
there are no security vulnerabilities"

AI: "I'll deploy to staging with your conditions. Let me check...

✓ All 847 tests passing
✓ Security scan: 0 critical, 0 high vulnerabilities
  (2 low-severity items flagged for review later)

Conditions met. Proceeding with deployment...
✓ Deployed to staging.yourapp.com

I found 2 low-severity security items. Would you like me to 
summarise them?"

This kind of pre-deployment analysis is exactly what modern AI-powered deployment troubleshooting tools are designed for.

Investigative deployment:

Developer: "What would happen if I deployed right now?"

AI: "If you deployed the current develop branch to staging:

**Changes:** 8 commits, +1,247 / -423 lines
**Risk assessment:** Medium
- Database migration adds new index (may take ~30s on production)
- New environment variable required: STRIPE_WEBHOOK_SECRET
- Dependency update: lodash 4.17.19 → 4.17.21 (security patch)

**Missing:** The STRIPE_WEBHOOK_SECRET isn't set in staging yet.

Would you like me to proceed anyway, or shall we add the 
environment variable first?"

The Technology Making This Possible

Several technological advances are converging to enable conversational deployments:

1. Large Language Models (LLMs)

Modern AI can understand nuanced natural language requests and translate them into specific actions. They handle ambiguity, ask clarifying questions when needed, and explain their actions in human terms.

2. Model Context Protocol (MCP)

MCP provides a standardised way for AI assistants to interact with external tools. A deployment platform that implements MCP can expose its capabilities—triggering deployments, reading logs, managing environment variables—in a way any compatible AI assistant can use.

For a technical deep dive, see MCP and the Future of AI-Integrated DevOps Tools.

flowchart TB
    subgraph "MCP-Enabled Deployment"
        User[Developer] --> AI[AI Assistant]

        AI <--> MCP[MCP Protocol]

        MCP <--> Deploy[DeployHQ API]
        MCP <--> Git[GitHub/GitLab]
        MCP <--> Monitor[Monitoring]

        Deploy --> Server[Servers]
    end

    style User fill:#64748B,color:#fff
    style AI fill:#0891B2,color:#fff
    style MCP fill:#0891B2,color:#fff
    style Deploy fill:#10B981,color:#fff
    style Git fill:#64748B,color:#fff
    style Monitor fill:#64748B,color:#fff
    style Server fill:#10B981,color:#fff

3. Contextual Awareness

AI assistants can now understand context across your entire development environment—your codebase, recent commits, deployment history, and current server state. This enables intelligent defaults and proactive warnings.

Designing for Conversational Deployment

If you're building or choosing deployment tools, here's what makes conversational interfaces effective:

Clear Mental Models

Users need to understand what the AI can and cannot do:

Developer: "Deploy to production and also update our DNS 
to point to the new server"

AI: "I can deploy to production, but I don't have access 
to your DNS settings. I'll proceed with the deployment, and 
you'll need to update DNS separately in your domain registrar.

Would you like me to continue with just the deployment?"

Appropriate Guardrails

Conversational doesn't mean careless. Production deployments should still require confirmation:

Developer: "Deploy to production"

AI: "You're about to deploy to production. This will affect 
your live users.

**Summary:**
- Branch: main (commit abc123)
- Changes: 5 commits since last deploy
- Last deploy: 3 days ago

Type 'confirm' or click [Deploy Now] to proceed."

DeployHQ already supports guardrails: Configure deployment approvals to require manual confirmation for production deployments, even when staging deploys automatically.

Graceful Handling of Ambiguity

Good conversational systems ask clarifying questions rather than guessing:

Developer: "Deploy the latest changes"

AI: "I see recent changes on multiple branches:
- main: 2 commits (bug fixes)
- develop: 8 commits (new features)
- feature/api-v2: 15 commits (API redesign)

Which branch would you like to deploy, and to which environment?"

Practical Implementation: A Prompt Library

While full conversational deployment is still emerging, you can approximate it today using AI assistants with well-crafted prompts.

Deployment Request Prompt

You are a deployment assistant for a web application. 
The user will make deployment requests in natural language.

Available actions:
- Deploy [branch] to [environment]
- Rollback [environment] to [version]
- Check status of [environment]
- Compare [environment1] and [environment2]

Current project context:
- Environments: staging, production
- Default branch: main
- Deployment tool: DeployHQ

When the user makes a request:
1. Confirm you understand the request
2. Identify any risks or missing information
3. Ask for confirmation before destructive actions
4. Execute and report results

User request: [USER_INPUT]

Status Check Prompt

Analyse the following deployment status and provide a 
human-readable summary:

- Include what was deployed and when
- Highlight any warnings or errors
- Suggest next steps if applicable

Status data:
[DEPLOYMENT_STATUS_JSON]

Respond conversationally, as if explaining to a colleague.

The Challenges Ahead

Conversational deployments aren't without challenges:

Trust and Verification

When deployments happen through conversation, how do you maintain an audit trail?

Traditional	Conversational
UI shows who clicked deploy	AI logs intent + actions
Settings visible in dashboard	AI explains inferred settings
Manual review of each option	AI requests confirmation for risks

DeployHQ's deployment history already captures who triggered each deployment and what changed—essential groundwork for conversational audit trails.

Handling Edge Cases

Natural language is ambiguous. Deploy the latest could mean different things:

Latest commit on the current branch?
Latest tag?
Latest successful build?

Good conversational systems develop conventions and ask when unclear.

Maintaining Control

There's a balance between convenience and control:

flowchart LR
    A[Full Manual Control] --> B[Guided Automation]
    B --> C[Conversational with Guardrails]
    C --> D[Full Autonomy]

    style A fill:#64748B,color:#fff
    style B fill:#64748B,color:#fff
    style C fill:#10B981,color:#fff
    style D fill:#F59E0B,color:#fff

The sweet spot is conversational with guardrails —natural language for intent, confirmation for critical actions, and clear explanations throughout.

What This Means for Developers

Conversational deployments will be particularly transformative for:

Solo Developers and Freelancers

No more remembering which button to click for which client's project. Just describe what you need: Deploy the Johnson website to their staging server.

Managing multiple client projects? DeployHQ's team features let you organise projects by client and set different permissions for each.

Teams Without Dedicated DevOps

Natural language lowers the barrier to deployment. Junior developers can deploy safely because the AI guides them through risks and confirms before proceeding.

When something does go wrong, AI-powered troubleshooting helps them fix it without escalating to senior team members.

High-Velocity Teams

When deployment is as easy as typing a message, shipping becomes faster. Teams can iterate more quickly without context-switching between development and operations tools.

Preparing for the Conversational Future

Even before full conversational deployment arrives, you can prepare:

Document Your Deployment Conventions

Create a reference that an AI could use to understand your setup:

deployment_conventions:
  environments:
    staging:
      purpose: "Testing before production"
      branch: develop
      auto_deploy: true
    production:
      purpose: "Live user-facing"
      branch: main
      requires_approval: true

  terminology:
    "latest": main branch HEAD
    "stable": most recent tag
    "hotfix": branches matching hotfix/*

Standardise Your Naming

Consistent naming helps AI understand intent:

feature/* branches → staging deployment candidates
hotfix/* branches → production deployment candidates
Clear environment names: staging, production, not server2, live-new

Build Confidence in Automation

If you don't trust automated deployments now, you won't trust conversational ones. Start by automating your staging deployments with DeployHQ's automatic deployments, then gradually extend automation to production with appropriate guardrails.

Key Takeaways

Conversational deployments represent the next evolution in how we ship code—from manual processes to clicks to commands to natural language. Here's what to remember:

Conversational deployment is about expressing intent, not following procedures
Technologies like LLMs and MCP are making this possible today
Good conversational systems include guardrails for critical actions
You can prepare now by documenting conventions and standardising naming
The goal is reduced friction without reduced control

The future of deployment is a conversation. And that conversation is starting now.

Continue Reading

How AI Coding Assistants Are Changing Deployments — The broader transformation
AI-Powered Deployment Troubleshooting — When things go wrong
MCP and the Future of AI-Integrated DevOps — The technical foundation

Ready to start your journey toward simpler deployments? Start your free DeployHQ trial and set up automatic deployments in minutes. It's the first step toward conversational deployment.

Have ideas for AI deployment features? Tell us on X — we'd love to hear what you'd build.

Turbo Deployments Explained: Deploy Faster with One Simple Trick

DeployHQ — Wed, 18 Feb 2026 08:41:46 +0000

If you've ever watched a deployment progress bar crawl across your screen, uploading file after file after file, you know the frustration. Traditional file-by-file deployments are one of the biggest time sinks in modern development workflows -- especially for projects with hundreds or thousands of files.

Turbo Deployments change the game entirely. Instead of transferring each file individually, Turbo bundles everything into a single compressed package, sends it in one transfer, and unpacks it on the server at local disk speed. The result? Deployments that are up to 10x faster than traditional methods.

In this guide, we'll cover how traditional deployments work (and why they're slow), how Turbo Deployments solve the problem, what you need on your server, when to use them, and how to enable the feature in DeployHQ. By the end, you'll have a clear understanding of whether Turbo is right for your workflow -- and how to start using it today.

The Old Way: Uploading Files One-by-One

Traditional deployments work like this:

Your Computer Your Server
|-- index.php -> |-- index.php (2 seconds)
|-- style.css -> |-- style.css (2 seconds)
|-- app.js -> |-- app.js (2 seconds)
|-- config.php -> |-- config.php (2 seconds)
+-- ... 500 more files +-- ... (1000 seconds!)

Each file makes its own trip across the internet. With 500 files, that's 500 separate connections. Every connection involves a handshake, authentication, file transfer, and confirmation -- all of which adds overhead. That connecting and disconnecting adds up to a LOT of wasted time, especially over high-latency connections or when deploying to servers in distant regions.

Think of it like: Carrying groceries from your car to your kitchen one item at a time. Sure, it works, but it's painfully slow!

The Turbo Way: Bundle, Send, Unpack

Turbo Deployments take a fundamentally different approach:

flowchart LR
    A[Your Files<br/>1000 files] --> B[Bundle<br/>.tar.gz]
    B --> C[Single Transfer<br/>to Server]
    C --> D[Unpack Locally<br/>on Server]
    D --> E[All Files<br/>in Place]

Instead of making hundreds of individual transfers, the entire deployment is compressed into a single .tar.gz archive, transferred once, and then extracted directly on the server. Since the extraction happens locally on the server's filesystem, it runs at disk speed rather than network speed.

Time saved: Instead of 1000 seconds, maybe 50 seconds total!

Think of it like: Putting all your groceries in bags, making ONE trip, then unpacking inside your kitchen.

How It Works Step by Step

Here's what happens behind the scenes when you trigger a Turbo Deployment:

Step 1: Bundle Everything

DeployHQ identifies all the files that need to be deployed (based on your Git diff or full deployment), then compresses them into a single .tar.gz archive. This is the same compression format used by Linux system administrators worldwide -- it's battle-tested and efficient.

Before deployment:
|-- app/
| |-- models/
| |-- views/
| +-- controllers/
|-- public/
| |-- css/
| +-- js/
+-- config/

(compress into one file)

deployment.tar.gz (one compressed file)

Text-based source code compresses extremely well. A project with 50MB of source files might compress down to 5-10MB, making the transfer even faster.

Step 2: Send One File

Your Computer ============> Your Server
    deployment.tar.gz
     (one fast transfer!)

Instead of 500 separate uploads with 500 connection handshakes, there's just ONE upload over a single SSH connection. This eliminates the per-file overhead that makes traditional deployments so slow.

Step 3: Server Unpacks

On your server:

deployment.tar.gz

(extract)

|-- app/
| |-- models/ [done]
| |-- views/ [done]
| +-- controllers/[done]
|-- public/
| |-- css/ [done]
| +-- js/ [done]
+-- config/ [done]

(all organized and ready!)

Your server extracts everything and puts files in the right places using rsync. Since this happens entirely ON the server, it's lightning fast -- no internet latency involved. The server's local disk I/O handles the heavy lifting, and modern SSDs can extract thousands of files in seconds.

Why Is This So Much Faster?

Three main reasons:

1. One Transfer Instead of Many

Every file transfer involves overhead: DNS resolution, TCP handshake, SSH authentication, channel setup, and confirmation. With traditional deployments, you pay this cost for every single file.

Traditional: 500 files = 500 separate connections = 500x overhead
Turbo: 500 files = 1 connection = 1x overhead

2. Compression Makes It Smaller

The .tar.gz package is compressed, so it's significantly smaller to transfer. Source code -- HTML, CSS, JavaScript, PHP, Python -- is highly compressible text. You'll typically see 70-90% compression ratios, meaning you're transferring a fraction of the original data.

3. Local Speed vs. Internet Speed

Once the package is on your server, unpacking happens at local disk speed (hundreds of MB/s on SSDs) instead of internet speed (typically 1-100 MB/s). This difference alone can account for a 10x improvement on the extraction phase.

Real-world benchmarks:

Scenario	Traditional	Turbo	Speedup
500 files, shared hosting	~15 min	~2 min	7.5x
1,000 files, VPS	~20 min	~3 min	6.7x
2,000+ files, dedicated	~40 min	~4 min	10x

What You Need to Use Turbo Deployments

Your server needs a few standard tools installed. The good news is that most Linux servers already have these out of the box:

SSH access (not just FTP)
tar (for unpacking -- included in virtually all Linux distributions)
gzip (for decompression -- also standard on Linux)
rsync (for organizing files into the correct locations)
jq (for reading deployment instructions -- easily installed via package manager)

Note: Turbo Deployments won't work with:

FTP-only servers (no SSH access)
SFTP-only connections (without full SSH shell access)
Cloud storage targets (like Amazon S3 or Google Cloud Storage)

But it works great with any regular Linux/Unix server where you have SSH access -- which covers the vast majority of web hosting environments, VPS providers, and dedicated servers.

When Should You Use Turbo Deployments?

Turbo Deployments are perfect when you:

Deploy projects with lots of files (100+)
Notice your current deployments feel slow
Have SSH access to your server
Want to reduce deployment downtime for your users

They're especially impactful for:

WordPress sites with lots of plugins and themes
Laravel/Symfony PHP apps with large vendor directories
React/Vue/Angular front-end builds with bundled assets
Node.js applications with extensive node_modules
Monorepos and multi-service projects

Thousands of teams already use DeployHQ to ship code faster. Turbo Deployments are one of the most impactful features for teams deploying medium-to-large projects.

How to Enable It

In DeployHQ:

Go to your server settings
Check if your server is compatible (DeployHQ will automatically detect this)
Enable Use Turbo Deployments
Deploy as normal -- everything else stays the same!

DeployHQ automatically checks if your server has the right tools installed. If something's missing, it'll gracefully fall back to regular deployments, so there's no risk in enabling it.

Turbo Deployments are available on all DeployHQ plans, including the free tier.

Troubleshooting

If Turbo Deployments aren't working as expected, here are the most common issues:

Server not compatible message: Your server is likely missing one of the required tools (tar, gzip, rsync, or jq). SSH into your server and install the missing package. On Ubuntu/Debian: sudo apt-get install rsync jq. On CentOS/RHEL: sudo yum install rsync jq.

Deployments falling back to traditional mode: DeployHQ runs a compatibility check before each Turbo deployment. Check your server logs or DeployHQ's deployment log for details on what failed the check.

Permission errors during extraction: The SSH user must have write permissions to the deployment directory. Ensure your deployment path is writable by the user specified in your server configuration.

Frequently Asked Questions

Can I use Turbo with zero-downtime deployments? Yes! Turbo Deployments work alongside DeployHQ's zero-downtime deployment feature. The compressed transfer happens first, then the atomic symlink switch ensures no downtime.

Will Turbo work with my build pipeline? Absolutely. Turbo Deployments handle the file transfer step. Your build commands run before the transfer, so compiled assets, minified files, and generated code all get bundled into the archive.

What if my server doesn't support Turbo? DeployHQ automatically falls back to traditional file-by-file deployment. You won't experience any errors -- just the standard deployment speed.

Is there a file size limit? There's no hard limit on the archive size. However, very large projects (10GB+) may benefit from using DeployHQ's config file exclusions to skip unnecessary files like test fixtures or documentation.

Does Turbo work with atomic deployments? Yes. Turbo handles the transfer; atomicity is managed by the deployment strategy. They complement each other perfectly.

The Bottom Line

Turbo Deployments are like using a moving truck instead of carrying boxes in your car. Same destination, way fewer trips, and you're done in a fraction of the time.

If you're deploying projects with more than a hundred files and have SSH access to your server, Turbo Deployments can save you serious time on every single deployment. For teams deploying multiple times a day, those minutes add up to hours saved every week.

Ready to speed up your deployments? Sign up for DeployHQ and enable Turbo Deployments today, or check out our pricing plans to find the right fit for your team. Questions? Reach out to us at support@deployhq.com or on Twitter @deployhq.

Serverless Deployments with DeployHQ: AWS Lambda, Vercel, and Netlify

DeployHQ — Mon, 16 Feb 2026 06:30:54 +0000

Serverless computing has revolutionized how we deploy applications, eliminating server management while enabling automatic scaling. Whether you're deploying to AWS Lambda, Vercel, or Netlify, DeployHQ can streamline your serverless deployment workflow. In this guide, you'll learn how to integrate serverless platforms with your existing deployment pipeline.

Understanding Serverless Deployments

Serverless doesn't mean no servers—it means you don't manage them. The platform handles infrastructure, scaling, and availability. Your focus shifts entirely to code and business logic.

flowchart LR
    subgraph "Traditional"
        T1[Code] --> T2[Build]
        T2 --> T3[Configure Server]
        T3 --> T4[Deploy]
        T4 --> T5[Scale Manually]
    end

    subgraph "Serverless"
        S1[Code] --> S2[Build]
        S2 --> S3[Deploy Function]
        S3 --> S4[Auto-Scale]
    end

If you're new to modern web architecture, check out our guide on JAMStack vs. Traditional CMS.

AWS Lambda Deployment with DeployHQ

AWS Lambda is the most mature serverless platform. Here's how to deploy Lambda functions using DeployHQ's build pipeline.

Project Structure

serverless-app/
├── src/
│ ├── handlers/
│ │ ├── api.js
│ │ ├── webhook.js
│ │ └── scheduler.js
│ └── lib/
│ └── database.js
├── package.json
├── serverless.yml
└── .deployhq/
    └── deploy.sh

Serverless Framework Configuration

# serverless.yml
service: my-serverless-api

provider:
  name: aws
  runtime: nodejs20.x
  region: ${env:AWS_REGION, 'us-east-1'}
  environment:
    DATABASE_URL: ${env:DATABASE_URL}
    API_KEY: ${env:API_KEY}

functions:
  api:
    handler: src/handlers/api.handler
    events:
      - http:
          path: /{proxy+}
          method: any
    timeout: 30
    memorySize: 512

  webhook:
    handler: src/handlers/webhook.handler
    events:
      - http:
          path: /webhook
          method: post

  scheduler:
    handler: src/handlers/scheduler.handler
    events:
      - schedule: rate(1 hour)

plugins:
  - serverless-offline

package:
  exclude:
    - node_modules/**
    - .git/**
    - tests/**
  include:
    - src/**

DeployHQ Build Commands

# Install dependencies
npm ci

# Run tests
npm test

# Package and deploy with Serverless Framework
npx serverless deploy --stage ${DEPLOY_ENVIRONMENT:-production}

# Output deployed endpoints
npx serverless info --stage ${DEPLOY_ENVIRONMENT:-production}

Environment Variables Setup

In DeployHQ project settings, add these environment variables:

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=xxx
AWS_REGION=us-east-1
DATABASE_URL=postgresql://...
API_KEY=xxx

For secure credential management, see our guide on protecting your API keys.

Vercel Deployment Integration

Vercel excels at deploying Next.js applications and serverless functions. While Vercel has its own Git integration, you can also deploy via DeployHQ for more control.

Project Structure for Vercel

nextjs-app/
├── pages/
│ ├── api/
│ │ ├── users.js
│ │ └── products.js
│ ├── index.js
│ └── about.js
├── components/
├── public/
├── package.json
├── vercel.json
└── next.config.js

Vercel Configuration

// vercel.json
{
  "version": 2,
  "builds": [
    {
      "src": "package.json",
      "use": "@vercel/next"
    }
  ],
  "routes": [
    {
      "src": "/api/(.*)",
      "dest": "/api/$1"
    }
  ],
  "env": {
    "DATABASE_URL": "@database_url",
    "NEXT_PUBLIC_API_URL": "@api_url"
  }
}

DeployHQ Build Commands for Vercel

# Install Vercel CLI
npm install -g vercel

# Install project dependencies
npm ci

# Run tests
npm test

# Build Next.js
npm run build

# Deploy to Vercel
vercel deploy --prod --token $VERCEL_TOKEN

# Or deploy preview for non-main branches
if ["$DEPLOY_BRANCH" != "main"]; then
    vercel deploy --token $VERCEL_TOKEN
else
    vercel deploy --prod --token $VERCEL_TOKEN
fi

Serverless API Route Example

// pages/api/users.js
import { db } from '../../lib/database';

export default async function handler(req, res) {
  const { method } = req;

  switch (method) {
    case 'GET':
      try {
        const users = await db.user.findMany({
          take: 50,
          orderBy: { createdAt: 'desc' }
        });
        res.status(200).json(users);
      } catch (error) {
        res.status(500).json({ error: 'Failed to fetch users' });
      }
      break;

    case 'POST':
      try {
        const user = await db.user.create({
          data: req.body
        });
        res.status(201).json(user);
      } catch (error) {
        res.status(400).json({ error: 'Failed to create user' });
      }
      break;

    default:
      res.setHeader('Allow', ['GET', 'POST']);
      res.status(405).end(`Method ${method} Not Allowed`);
  }
}

For Next.js deployment specifics, see our guide on deploying a Next.js application.

Netlify Functions Deployment

Netlify offers a simpler serverless experience with automatic function deployment.

Project Structure

netlify-app/
├── netlify/
│ └── functions/
│ ├── hello.js
│ └── submit-form.js
├── src/
│ └── index.html
├── package.json
└── netlify.toml

Netlify Configuration

# netlify.toml
[build]
  command = "npm run build"
  publish = "dist"
  functions = "netlify/functions"

[build.environment]
  NODE_VERSION = "20"

[functions]
  directory = "netlify/functions"

[[redirects]]
  from = "/api/*"
  to = "/.netlify/functions/:splat"
  status = 200

Netlify Function Example

// netlify/functions/submit-form.js
const { createClient } = require('@supabase/supabase-js');

const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_KEY
);

exports.handler = async (event, context) => {
  if (event.httpMethod !== 'POST') {
    return {
      statusCode: 405,
      body: JSON.stringify({ error: 'Method not allowed' })
    };
  }

  try {
    const data = JSON.parse(event.body);

    // Validate input
    if (!data.email || !data.message) {
      return {
        statusCode: 400,
        body: JSON.stringify({ error: 'Missing required fields' })
      };
    }

    // Save to database
    const { error } = await supabase
      .from('submissions')
      .insert([data]);

    if (error) throw error;

    return {
      statusCode: 200,
      body: JSON.stringify({ message: 'Form submitted successfully' })
    };
  } catch (error) {
    return {
      statusCode: 500,
      body: JSON.stringify({ error: 'Internal server error' })
    };
  }
};

DeployHQ Build Commands for Netlify

# Install Netlify CLI
npm install -g netlify-cli

# Install dependencies
npm ci

# Build site
npm run build

# Deploy to Netlify
netlify deploy --prod --auth $NETLIFY_AUTH_TOKEN --site $NETLIFY_SITE_ID

Edge Functions: The Next Evolution

Edge functions run closer to your users, reducing latency. Both Vercel and Netlify support them.

flowchart TB
    subgraph "Traditional Lambda"
        U1[User in Tokyo] --> R1[us-east-1]
        R1 --> U1
    end

    subgraph "Edge Functions"
        U2[User in Tokyo] --> E1[Tokyo Edge]
        E1 --> U2
    end

    style E1 fill:#90EE90
    style R1 fill:#FFB6C1

Vercel Edge Function Example

// pages/api/geo.js
export const config = {
  runtime: 'edge',
};

export default function handler(request) {
  const { geo } = request;

  return new Response(
    JSON.stringify({
      country: geo?.country || 'Unknown',
      city: geo?.city || 'Unknown',
      region: geo?.region || 'Unknown',
    }),
    {
      status: 200,
      headers: {
        'Content-Type': 'application/json',
      },
    }
  );
}

Netlify Edge Function Example

// netlify/edge-functions/geo.js
export default async (request, context) => {
  const { country, city } = context.geo;

  return new Response(
    JSON.stringify({
      country: country?.name || 'Unknown',
      city: city || 'Unknown',
    }),
    {
      headers: {
        'Content-Type': 'application/json',
      },
    }
  );
};

export const config = {
  path: '/api/geo',
};

Deployment Pipeline Flow

sequenceDiagram
    participant Dev as Developer
    participant DHQ as DeployHQ
    participant Build as Build Server
    participant Platform as Serverless Platform

    Dev->>DHQ: git push
    DHQ->>Build: Trigger build
    Build->>Build: npm install
    Build->>Build: npm test
    Build->>Build: npm run build
    Build->>Platform: Deploy (CLI)
    Platform->>Platform: Validate
    Platform->>Platform: Deploy functions
    Platform->>Build: Success + URLs
    Build->>DHQ: Complete
    DHQ->>Dev: Notification

Environment Management

Managing environments in serverless requires careful configuration:

// config/index.js
const environments = {
  development: {
    apiUrl: 'http://localhost:3000/api',
    databaseUrl: process.env.DEV_DATABASE_URL,
  },
  staging: {
    apiUrl: 'https://staging-api.example.com',
    databaseUrl: process.env.STAGING_DATABASE_URL,
  },
  production: {
    apiUrl: 'https://api.example.com',
    databaseUrl: process.env.PROD_DATABASE_URL,
  },
};

const environment = process.env.NODE_ENV || 'development';
export const config = environments[environment];

For more on environment management, see managing multiple environments with DeployHQ.

Cold Starts and Performance

Cold starts are the biggest challenge in serverless. Mitigate them with:

Keep Functions Warm

// AWS Lambda warmer
exports.handler = async (event) => {
  // Check if this is a warming call
  if (event.source === 'serverless-plugin-warmup') {
    console.log('Warming up!');
    return 'Warmed!';
  }

  // Normal handler logic
  return await handleRequest(event);
};

Optimize Bundle Size

// package.json
{
  "dependencies": {
    // Use lighter alternatives
    "date-fns": "^2.30.0" // Instead of moment.js
  },
  "devDependencies": {
    "esbuild": "^0.19.0" // Fast bundler
  }
}

Connection Pooling

// lib/database.js
import { PrismaClient } from '@prisma/client';

// Reuse connection across invocations
let prisma;

if (process.env.NODE_ENV === 'production') {
  prisma = new PrismaClient();
} else {
  // Prevent too many connections in development
  if (!global.prisma) {
    global.prisma = new PrismaClient();
  }
  prisma = global.prisma;
}

export { prisma };

Monitoring and Debugging

AWS CloudWatch Integration

// Structured logging for CloudWatch
const log = (level, message, data = {}) => {
  console.log(JSON.stringify({
    timestamp: new Date().toISOString(),
    level,
    message,
    ...data,
    requestId: process.env.AWS_REQUEST_ID,
  }));
};

exports.handler = async (event) => {
  log('info', 'Request received', { path: event.path });

  try {
    const result = await processRequest(event);
    log('info', 'Request completed', { statusCode: 200 });
    return result;
  } catch (error) {
    log('error', 'Request failed', { error: error.message });
    throw error;
  }
};

Best Practices Summary

Keep functions small and focused on single tasks
Minimize cold starts with proper initialization
Use environment variables for configuration
Implement proper error handling with structured logging
Test locally before deploying (serverless-offline, netlify dev)
Monitor performance and set up alerts
Use edge functions for latency-sensitive operations
Bundle dependencies efficiently

Getting Started

Ready to go serverless? Here's your action plan:

Choose your platform (Lambda, Vercel, Netlify)
Set up project structure
Configure DeployHQ build commands
Add environment variables
Deploy and monitor

For traditional deployments, see our CI/CD pipeline guide.

Questions about serverless deployments? Contact support@deployhq.com or follow @deployhq for the latest guides.

SFTP vs SCP vs rsync: Choosing the Right File Transfer Method

DeployHQ — Fri, 13 Feb 2026 06:45:03 +0000

Every deployment ultimately comes down to transferring files from one machine to another. Whether you're pushing code to a server, syncing assets to a staging environment, or downloading backups, you need a secure file transfer method. The three most common options — SFTP, SCP, and rsync — all use SSH for encryption, but they work very differently under the hood.

This guide compares all three with practical examples and helps you choose the right one for your deployment workflow.

Quick Comparison

Feature	SFTP	SCP	rsync
Protocol	SSH File Transfer Protocol	Secure Copy (over SSH)	Remote sync (over SSH)
Transfer type	Full file transfer	Full file transfer	Delta transfer (only changes)
Resume interrupted transfers	Yes	No	Yes
Directory listing	Yes	No	Yes
Interactive mode	Yes (like FTP)	No (command-line only)	No (command-line only)
Bandwidth efficiency	Moderate	Moderate	Excellent (delta algorithm)
Status in 2025	Active, recommended	Deprecated in OpenSSH 9.0	Active, recommended
Best for	General file management	Legacy one-off copies	Incremental deployments

SFTP: SSH File Transfer Protocol

SFTP is the modern standard for secure file transfer. Despite the name, it has nothing to do with FTP — it's a completely separate protocol that runs over SSH.

How It Works

SFTP establishes an SSH connection and then provides a file transfer subsystem on top of it. You get a full set of file operations: upload, download, rename, delete, list directories, change permissions.

Command Examples

Upload a file:

sftp user@server.example.com
sftp> put index.html /var/www/html/
sftp> exit

Non-interactive upload:

sftp user@server.example.com <<EOF
put -r dist/ /var/www/html/
EOF

Upload with a specific SSH key:

sftp -i ~/.ssh/deploy_key user@server.example.com

Download a directory recursively:

sftp user@server.example.com
sftp> get -r /var/www/html/backups/ ./local-backups/

When to Use SFTP

General-purpose file management on remote servers
Interactive file browsing and operations
When you need resume support for large transfers
As a replacement for FTP (which is insecure)
Automated deployments via tools like DeployHQ

SCP: Secure Copy Protocol

SCP is the simplest file transfer method — it copies files over SSH with a single command. However, OpenSSH deprecated the SCP protocol in version 9.0 (released April 2022) in favor of SFTP.

The Deprecation

Modern scp commands actually use SFTP internally by default (since OpenSSH 9.0). The scp command still exists for backward compatibility, but the underlying protocol is now SFTP. You can force the legacy SCP protocol with -O, but there's rarely a reason to.

Command Examples

Copy a file to a remote server:

scp index.html user@server.example.com:/var/www/html/

Copy a directory recursively:

scp -r dist/ user@server.example.com:/var/www/html/

Copy with a specific SSH key:

scp -i ~/.ssh/deploy_key -r dist/ user@server.example.com:/var/www/html/

Download from remote:

scp user@server.example.com:/var/www/html/backup.tar.gz ./

When to Use SCP

Quick one-off file copies where you don't need interactivity
Legacy scripts that already use scp (they'll use SFTP under the hood now)
Simple transfers where rsync's features aren't needed

rsync: The Delta Transfer Tool

rsync is the most powerful of the three. Its killer feature is the delta transfer algorithm — it compares files on both sides and only transfers the differences. For deployments where most files haven't changed, this is dramatically faster than copying everything.

How It Works

flowchart LR
  A[Local files] --> B[rsync compares checksums]
  C[Remote files] --> B
  B --> D[Transfer only changed bytes]
  D --> E[Updated remote files]

rsync splits each file into blocks, computes checksums, and sends only the blocks that differ. A 10 MB file with a one-line change might only transfer a few kilobytes.

Command Examples

Sync a directory to a remote server:

rsync -avz dist/ user@server.example.com:/var/www/html/

Flags explained:

-a (archive): preserves permissions, timestamps, symlinks, ownership
-v (verbose): shows progress
-z (compress): compresses data during transfer

Sync with delete (remove files on remote that don't exist locally):

rsync -avz --delete dist/ user@server.example.com:/var/www/html/

Dry run (see what would change without actually transferring):

rsync -avzn --delete dist/ user@server.example.com:/var/www/html/

Exclude files:

rsync -avz --exclude='node_modules' --exclude='.env' \
  ./ user@server.example.com:/var/www/html/

Use a specific SSH key:

rsync -avz -e "ssh -i ~/.ssh/deploy_key" \
  dist/ user@server.example.com:/var/www/html/

When to Use rsync

Deployments with large codebases where most files don't change
Syncing directories that change incrementally
Backups (only transfer what changed since last backup)
Any transfer where bandwidth is limited or expensive

Performance Comparison

For a project with 1,000 files (50 MB total) where 10 files changed since the last deploy:

Method	First deploy	Subsequent deploys
SFTP	~50 MB transferred	~50 MB transferred
SCP	~50 MB transferred	~50 MB transferred
rsync	~50 MB transferred	~500 KB transferred

rsync's advantage grows with project size. For a 500 MB project with small daily changes, rsync saves massive bandwidth and time.

Security Considerations

All three methods use SSH for encryption. The security fundamentals are the same:

Authentication : Use SSH key pairs instead of passwords
Port : Default is 22 — consider changing it to reduce automated scanning
Key management : Use dedicated deploy keys with restricted permissions
Firewall : Allow SSH only from known IP addresses

Deploy Key Best Practice

Create a dedicated key pair for deployments:

ssh-keygen -t ed25519 -f ~/.ssh/deploy_key -C "deploy@example.com"

On the server, restrict the key to specific commands in ~/.ssh/authorized_keys:

command="rsync --server --daemon .",no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA... deploy@example.com

FTP vs SFTP

If you're still using plain FTP, stop. FTP transmits passwords and file contents in plain text — anyone on the network can read them.

Feature	FTP	SFTP
Encryption	None (plain text)	SSH encryption
Password security	Sent in clear text	Encrypted
File integrity	No verification	Checksum verification
Firewall friendly	Requires multiple ports	Single port (22)
Resume support	Yes	Yes

There is no reason to use FTP in 2025. If your hosting provider only supports FTP, it's time to switch providers.

How This Relates to Deployment

When you deploy with DeployHQ, you choose your transfer protocol during project setup. DeployHQ supports SFTP, FTP/S, and direct integrations with cloud services like S3 and DigitalOcean.

For server deployments, SFTP is the default and recommended protocol. DeployHQ connects to your server via SSH, compares the files in your Git repository with what's on the server, and transfers only the changed files — similar to how rsync works.

This means:

First deploy transfers all files
Subsequent deploys only transfer changed files (fast and bandwidth-efficient)
Deleted files are removed from the server automatically
Permissions are preserved during transfer

Whether you push from GitHub or GitLab, DeployHQ handles the file transfer securely. For agencies managing dozens of client servers, having a consistent, secure transfer method across all projects reduces operational risk.

FAQ

Is rsync better than SFTP for deployments? For manual deployments, yes — rsync's delta algorithm is significantly faster for incremental updates. But deployment tools like DeployHQ already implement similar delta logic over SFTP, so you get the speed benefit without writing rsync commands.

Can I use rsync with a non-standard SSH port? Yes: rsync -avz -e "ssh -p 2222" src/ user@server:/dest/

Does SFTP support file permissions? Yes. SFTP can set permissions, ownership, and timestamps on remote files, similar to rsync's archive mode.

Is SCP really deprecated? The SCP protocol is deprecated, but the scp command still works — it just uses SFTP internally now. Your existing scripts won't break, but there's no reason to write new ones using scp when sftp or rsync do everything better.

Which protocol does DeployHQ use?DeployHQ supports SFTP (recommended), FTP/S, and various cloud provider APIs. SFTP connections use SSH key authentication for maximum security.

For most deployments, SFTP is the safe default. For manual syncing of large directories, rsync saves significant time and bandwidth. And for everything else, let your deployment tool handle the transfer protocol for you.

Try DeployHQ free — deploy via SFTP with automatic delta transfers on every push. See pricing for team plans.

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

DeployHQ vs Laravel Forge: How They Differ and How to Use Them Together

DeployHQ — Wed, 11 Feb 2026 08:08:54 +0000

If you're a Laravel developer, there's a good chance you've used Laravel Forge to provision and manage your servers. Forge is excellent at what it does — spinning up a fully configured server with Nginx, PHP, MySQL, Redis, and SSL in under a minute.

But once your server is running, how does your code actually get there?

Forge includes a basic push-to-deploy feature, but as your application grows — multiple environments, build steps, team workflows — you may find yourself wanting more control over the deployment process itself. That's where DeployHQ comes in.

This guide breaks down what each tool does, where they overlap, and how to use them together for a deployment workflow that covers both server management and code delivery.

What Laravel Forge Does

Forge is a server provisioning and management platform. Its primary job is turning a bare VPS from providers like DigitalOcean, AWS, or Hetzner into a fully configured application server.

What Forge handles:

Server provisioning : One-click setup of Nginx, PHP (multiple versions), MySQL/PostgreSQL, Redis, Memcached
SSL certificates : Free Let's Encrypt certificates with auto-renewal
Security : Firewall configuration, SSH key management, automatic security updates
Process management : Queue workers (Supervisor), cron job scheduling, daemon processes
Monitoring : CPU, memory, and disk usage dashboards
Basic deployments : Push-to-deploy from GitHub, GitLab, or Bitbucket with a configurable deploy script

Forge's deployment feature runs a shell script on your server when you push to a branch. The default script does a git pull, runs composer install, and restarts PHP-FPM. For simple apps, this works fine.

What DeployHQ Does

DeployHQ is a deployment pipeline platform. It focuses entirely on getting your code from a repository to one or more servers reliably, with build pipelines, atomic releases, and full visibility into what was deployed and when.

What DeployHQ handles:

Build pipelines : Run composer install, npm run build, asset compilation, and other build steps on DeployHQ's build servers — not on your production machine
Atomic deployments : Release-based deploys with instant rollback, so a failed deployment never leaves your site in a broken state
Multi-server deploys : Push to staging and production from the same pipeline with different configurations
Deployment dashboard : Visual history of every deployment, with logs, diffs, and status
Framework-agnostic : Works with PHP, Node.js, Python, Ruby, .NET, and any other stack
Integrations : Deployment notifications to Slack, Discord, Teams, plus error tracking and cache purging
SSH/SFTP/FTP support : Deploys to any server you can connect to

Side-by-Side Comparison

Capability	Forge	DeployHQ	Both Together
Server provisioning	Yes — full stack setup	No	Forge provisions, DeployHQ deploys
SSL/domain management	Yes	No	Forge handles SSL
PHP version management	Yes	No	Forge manages PHP
Queue workers / cron	Yes	No	Forge manages processes
Build pipeline	No — runs on server	Yes — dedicated build servers	DeployHQ builds, Forge serves
Atomic/zero-downtime deploys	Yes (new sites only)	Yes (any project)	DeployHQ handles releases
Multi-server deployment	No	Yes	Deploy to staging + production
Visual deployment history	Basic	Detailed with logs and diffs	Full visibility via DeployHQ
Rollback	Keep last 4 releases	Instant rollback to any release	DeployHQ rollbacks
Framework support	PHP-focused	Any language/framework	Full flexibility
Third-party integrations	Limited	Extensive (Slack, Discord, Bugsnag, Cloudflare)	DeployHQ integrations

How They Work Together

The ideal setup uses each tool for what it does best: Forge manages your infrastructure, DeployHQ manages your deployments.

flowchart TD
    subgraph Developer
        A["Git Push to GitHub/GitLab"]
    end

    subgraph DeployHQ ["DeployHQ (Build & Deploy)"]
        B["Detect Push"]
        C["Run Build Pipeline"]
        D["composer install"]
        E["npm run build"]
        F["php artisan optimize"]
        G["Deploy via SSH"]
    end

    subgraph Forge ["Forge-Provisioned Server"]
        H["Nginx + PHP-FPM"]
        I["MySQL / PostgreSQL"]
        J["Redis + Queue Workers"]
        K["SSL + Firewall"]
    end

    A --> B
    B --> C
    C --> D --> E --> F --> G
    G --> H
    H --> I
    H --> J
    H --> K

Setting Up DeployHQ With a Forge Server

Here's how to connect DeployHQ to a server provisioned by Forge.

Step 1: Provision Your Server on Forge

Create your server on Forge as usual — choose your provider, select your PHP version, and let Forge set up the full stack. Make note of the server's IP address.

Step 2: Get Your DeployHQ SSH Public Key

In DeployHQ, go to your project (or create a new one) and navigate to the Server settings. DeployHQ will show you its SSH public key. Copy it.

Step 3: Add the SSH Key to Your Forge Server

In Forge, go to your server's SSH Keys section and add DeployHQ's public key. This authorizes DeployHQ to connect and deploy files. For more on SSH key setup, see our guide on creating SSH keys for DeployHQ.

Step 4: Create a DeployHQ Server Entry

Back in DeployHQ, configure the server connection:

Protocol : SSH/SFTP
Hostname : Your Forge server's IP address
Port : 22
Username : forge (Forge's default deploy user)
Deploy path : /home/forge/your-site.com/current (or your site's root)

Step 5: Configure Your Build Pipeline

This is where DeployHQ shines. Instead of running build commands on your production server, configure them in DeployHQ's build pipeline:

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

These run on DeployHQ's build servers, keeping your production server lean.

Step 6: Configure SSH Commands

Add post-deployment SSH commands to run on your Forge server after files are transferred:

cd /home/forge/your-site.com
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan queue:restart

Step 7: Enable Zero-Downtime Deployments

In your DeployHQ project, enable atomic deployments for release-based deploys with instant rollback. This pairs well with database migration strategies for zero-downtime.

Step 8: Disable Forge's Push-to-Deploy

To avoid double deployments, disable Forge's built-in push-to-deploy feature for this site. Go to your site in Forge, navigate to Deployments , and toggle off Quick Deploy. DeployHQ will handle triggering deployments from now on.

A Complete Laravel Deployment Example

Here's what a full deployment looks like with both tools working together:

# Build phase (runs on DeployHQ build servers)
composer install --no-dev --optimize-autoloader --no-interaction
npm ci --production
npm run build

# After deployment (SSH commands on Forge server)
cd /home/forge/your-site.com
php artisan down --retry=60
php artisan migrate --force
php artisan config:cache
php artisan route:cache
php artisan view:cache
php artisan event:cache
php artisan storage:link
php artisan up
php artisan queue:restart

With zero-downtime deployments enabled, the artisan down/up commands become optional — your users will never see a maintenance page.

When to Use Forge Alone

Forge's built-in deployment works well if:

You have a single server with a single environment
Your app has no build step (no npm, no webpack, no Vite)
You're comfortable with git pull happening directly on your server
You don't need deployment rollbacks or multi-server deploys

For a straightforward Laravel API or a small site, Forge's push-to-deploy is often enough.

When to Add DeployHQ

Consider pairing with DeployHQ when:

You need build steps like npm run build or composer install --no-dev and don't want them running on production
You deploy to multiple servers (staging, production, or multiple regions)
You want visual deployment history with detailed logs and diffs
You need instant rollback without SSH-ing into your server
Your team needs deployment notifications in Slack, Discord, or Teams
You work with multiple frameworks — not just Laravel — and want a unified deployment tool
You manage client projects as an agency and need consistent workflows across different stacks

For a deeper look at PHP deployment strategies, see our comparison of PHP application servers.

Handling Environment Variables

One area that needs attention when using both tools is environment variable management. Forge manages your .env file on the server directly — you edit it through Forge's UI.

When DeployHQ deploys, it should not overwrite the .env file. Add .env to your excluded files list in DeployHQ's server configuration. This way, Forge keeps managing your environment secrets while DeployHQ handles code delivery.

For advanced setups, you can also use encrypted environment variables with Dotenvx to commit encrypted .env files directly to your repository.

FAQ

Can I use DeployHQ's build pipeline with Forge's zero-downtime deployments?

It's better to choose one tool for deployment management. If you're using DeployHQ for deployments, disable Forge's deploy feature and use DeployHQ's atomic deployments instead. Running both will cause conflicts.

Does DeployHQ replace Forge?

No. They serve different purposes. Forge provisions and manages your server infrastructure (PHP, Nginx, SSL, databases, queues). DeployHQ handles the deployment pipeline (building, transferring, and releasing code). You still need Forge (or manual server setup) for the server itself.

What about Laravel Envoyer?

Envoyer is Laravel's dedicated zero-downtime deployment tool. It sits between Forge's basic deploys and a full tool like DeployHQ. DeployHQ offers broader framework support, built-in build pipelines, and more integrations. If you only deploy Laravel apps, Envoyer is a solid option. If you work across multiple stacks, DeployHQ is more versatile.

Can I deploy to a Forge server via FTP?

Yes, but SSH/SFTP is recommended. Forge servers come with SSH configured, and DeployHQ's SSH deployment is faster and more secure than FTP. FTP should only be used if SSH is unavailable.

Do I still need to manage SSH keys on Forge?

Yes. You'll add DeployHQ's public SSH key to your Forge server so DeployHQ can connect. After that, deployments are fully automated — no manual SSH required.

Ready to level up your Laravel deployment workflow? Sign up for DeployHQ and connect it to your Forge servers in minutes. For questions, reach out to support@deployhq.com or find us on X @deployhq.

What's New in PHP 2026: Modern Features for Production

DeployHQ — Mon, 09 Feb 2026 10:54:09 +0000

The PHP ecosystem is experiencing a renaissance. After years of steady improvements, PHP 8.5 and the upcoming PHP 8.6 are introducing features that fundamentally change how we write and deploy production applications. If you're still thinking of PHP as that language from 2010, it's time to look again.

The practical implication for engineering teams is bigger than syntax. Language-level improvements now directly affect deployment safety, debugging speed, and how quickly teams can ship changes with confidence. Features like the pipe operator and improved fatal-error backtraces can reduce friction in both day-to-day development and incident response.

For teams running production workloads, the key is not chasing every new feature immediately. The goal is a controlled migration path: verify compatibility in staging, adopt stable features incrementally, and delay pre-GA features until they are finalized. This guide focuses on that production-first approach.

The Evolution Nobody Expected

For development teams managing production deployments, staying current with language features isn't just about writing cleaner code—it's about maintaining competitive advantage. While your deployment pipeline might be humming along perfectly with PHP 8.3, the features landing in 2026 will change how you architect, test, and scale your applications.

The question isn't whether to upgrade. It's how to do it safely, without breaking production.

What's Actually New in PHP 8.5 and 8.6?

PHP 8.5: Available Now (Released November 2025)

Pipe Operator The pipe operator enables functional composition, letting you chain operations without nested function calls:

$result = $data
    |> (fn($x) => array_filter($x, fn($item) => $item['active']))
    |> (fn($x) => array_map(fn($item) => $item['name'], $x))
    |> array_map(...)
    |> array_values(...);

This replaces the nested pyramid of doom and makes data transformation pipelines readable top-to-bottom.

Object Cloning with Data PHP 8.5 also introduces clone improvements that allow property reassignment during cloning through the new withProperties parameter. This reduces clone-then-modify boilerplate and makes object updates more explicit.

Closures in Attributes Decorators just got more powerful:

#[Route(path: '/api/users', middleware: fn() => new AuthMiddleware())]
class UserController { }

This enables more expressive metadata and reduces boilerplate in framework code.

Fatal Error Backtraces Stack traces now display for fatal errors. If you've ever debugged a segfault or memory exhaustion issue in production, you know why this matters.

PHP 8.6: Targeted for Late 2026

Partial Function Application (PFA)Partial function application is being developed for PHP 8.6 and can significantly improve reusable callables for functional workflows. Because this is still evolving, production teams should treat syntax details as provisional until final GA.

Pattern Matching (Under Discussion)Pattern matching has also been discussed for future versions, but production planning should assume this is not available until a final RFC is accepted and released.

Why These Features Matter for Production Teams

1. Deployment Safety Through Readable Code

The pipe operator and improved diagnostics make transformation code and runtime failures easier to reason about. During code reviews and incident response, you can trace data flow at a glance. Less cognitive load means fewer deployment mistakes.

2. Performance Without Complexity

FrankenPHP is a modern PHP runtime that many teams are evaluating in 2026. Depending on workload and architecture, it can improve throughput and latency, especially with worker mode and long-running processes. Measure in your own environment before committing to migration.

3. Migration Path Clarity

These features are backwards-compatible. You can deploy PHP 8.5 today, test thoroughly, and adopt features incrementally. Your existing PHP 8.3 code runs unchanged while you modernize hot paths.

Real-World Migration Scenarios

Scenario 1: API Data Transformation Pipeline

Before (PHP 8.3):

public function transform(array $data): array {
    $filtered = array_filter($data, fn($item) => $item['active']);
    $mapped = array_map(fn($item) => [
        'id' => $item['id'],
        'name' => strtoupper($item['name'])
    ], $filtered);
    return array_values($mapped);
}

After (PHP 8.5):

public function transform(array $data): array {
    return $data
        |> (fn($x) => array_filter($x, fn($item) => $item['active']))
        |> (fn($x) => array_map(
            fn($item) => ['id' => $item['id'], 'name' => strtoupper($item['name'])],
            $x
        ))
        |> array_values(...);
}

The logic is identical, but the after version reads like a declarative pipeline. When this breaks at 3am, you'll appreciate the difference.

Scenario 2: Configuration Object Updates

Before:

$config = clone $baseConfig;
$config->database = 'production';
$config->debug = false;
$config->cacheEnabled = true;

After (PHP 8.5):

$config = clone $baseConfig with [
    'database' => 'production',
    'debug' => false,
    'cacheEnabled' => true
];

One atomic operation. Less room for partial updates to slip through during deployment.

Scenario 3: Logger Helper with Less Repetition

Before (PHP 8.3):

$logger->log('INFO', 'User logged in');
$logger->log('INFO', 'Session created');
$logger->log('INFO', 'Cache warmed');

After (works today):

$info = fn(string $message) => $logger->log('INFO', $message);
$info('User logged in');
$info('Session created');
$info('Cache warmed');

Less repetition, more maintainable, and easier to refactor. If PFA lands in stable PHP 8.6, this pattern can become even cleaner.

How to Deploy PHP 8.5/8.6 Safely

Step 1: Test in a Build Pipeline

DeployHQ's build pipelines let you specify PHP versions for each project. Set up a staging deployment with PHP 8.5, run your full test suite, and verify behavior before touching production.

Configure your .deployhq.yaml:

build:
  php_version: 8.5
  commands:
    - composer install --no-dev
    - php artisan test

Step 2: Gradual Rollout Strategy

Use zero-downtime deployments to update servers one at a time. If a server with PHP 8.5 shows errors, rollback is instant.

Step 3: Monitor Fatal Error Backtraces

PHP 8.5's new fatal error backtraces will surface issues you couldn't debug before. Integrate with your error monitoring (Sentry, Rollbar) and watch for new patterns during the first week post-deployment.

Step 4: Adopt Features Incrementally

Don't rewrite everything. Start with new code using PHP 8.5 features like pipe operators and improved diagnostics. Refactor hot paths during regular maintenance. After 3-6 months, you'll have a modern codebase without a risky big bang deployment.

DeployHQ and PHP 2026

DeployHQ supports custom PHP versions in build environments, making PHP 8.5 and 8.6 testing straightforward. Key deployment capabilities for PHP 2026 features:

Build Pipelines : Test new PHP versions before production
Zero-Downtime Releases : Roll out PHP upgrades without user impact
Atomic Deployments : All-or-nothing deployment prevents partial updates
Rollback Support : Instant revert if issues surface post-deployment

Whether you're deploying Laravel with our Laravel guide or custom PHP applications using 5 powerful deployment methods, DeployHQ handles version transitions smoothly.

Key Takeaways

PHP 8.5 is production-ready with pipe operator, enhanced cloning, and fatal error backtraces
PHP 8.6 (target late 2026) may include partial function application and other features still in active RFC development
Backwards compatibility means safe, incremental adoption without deployment risk
FrankenPHP may provide meaningful performance gains depending on workload and runtime model
Migration path : Test in staging with build pipelines, deploy with zero-downtime strategies

Frequently Asked Questions

Should I upgrade to PHP 8.5 immediately?

Not necessarily. If your application is stable on PHP 8.3, wait until your next planned deployment window. Test thoroughly in staging first. The features are backwards-compatible, so there's no urgency—but there's also minimal risk once you've validated.

Will PHP 8.5 break my existing code?

Unlikely. The new features are additive. Your PHP 8.3 code should run unchanged on 8.5. However, always test in a build pipeline before deploying to production. Third-party dependencies might need updates.

How do I test PHP 8.5 without affecting production?

Use DeployHQ's staging environments with custom PHP versions. Deploy your app to a staging server with PHP 8.5, run your test suite, and verify behavior. Only promote to production after validation.

What's the performance difference between PHP 8.3 and 8.5?

Core language performance is similar (incremental improvements). The bigger gains often come from runtime choices and architecture (for example, FrankenPHP worker mode in suitable workloads). The new features also encourage clearer code that is easier to optimize and maintain.

When should I adopt the pipe operator and PFA?

Start using pipe operators in new code immediately after upgrading to PHP 8.5. For PFA, wait for final stable PHP 8.6 syntax before broad adoption. Refactor existing code during regular maintenance cycles—prioritize hot paths and complex data transformations.

Do I need to update Composer packages for PHP 8.5?

Check your dependencies with composer outdated. Most popular packages already support PHP 8.5. Laravel, Symfony, and WordPress are all compatible. If a package doesn't support 8.5, open an issue or find alternatives—community support for 8.5 is strong.

Can I use PHP 8.6 features today?

Not in production yet. PHP 8.6 is currently targeted for late 2026, and features may still change before GA. You can test pre-release versions locally, but avoid production deployment until stable release.

What's the best deployment strategy for PHP version upgrades?

Use zero-downtime deployments to update servers sequentially. Deploy to one server, monitor for 15-30 minutes, then continue. If issues arise, rollback is instant. This minimizes risk while maintaining availability.

Should I switch to FrankenPHP now?

FrankenPHP is production-ready for many new projects. For existing apps, evaluate whether observed gains in your workload justify migration effort. It pairs well with PHP 8.5 features, but PHP-FPM with Nginx remains a solid choice.

Where can I get help with PHP 8.5 deployment issues?

Check DeployHQ's support documentation for build pipeline and deployment configuration. For account-specific help, reach out to DeployHQ support.

Next Steps

Ready to try PHP 8.5 in your deployment pipeline?

Read the official PHP 8.5 release notes on php.net (linked below)
Set up a staging environment with DeployHQ build pipelines
Test your application with PHP 8.5 before deploying to production
Monitor performance and errors after deployment
Incrementally adopt new features in your codebase

Resources

Official Documentation

DeployHQ Resources

Ready to deploy PHP 8.5 safely? Start your free trial and test new PHP versions in isolated build pipelines before production. Deploy with confidence, rollback instantly if needed.

API Versioning and Deployment Strategies: Rolling Out Breaking Changes Safely

DeployHQ — Thu, 05 Feb 2026 06:50:35 +0000

Rolling out API changes without breaking existing clients is one of the most challenging aspects of backend development. Whether you're adding new features, deprecating old endpoints, or making breaking changes, proper versioning strategies ensure smooth deployments. In this guide, you'll learn how to implement API versioning and safely deploy breaking changes using DeployHQ.

Why API Versioning Matters

APIs are contracts with your consumers. Breaking changes can:

Crash mobile apps that haven't updated
Break integrations with third-party services
Frustrate developers who depend on your API
Damage trust with API consumers

flowchart TD
    subgraph "Without Versioning"
        A[API Change] --> B[All Clients Break]
        B --> C[Angry Users]
    end

    subgraph "With Versioning"
        D[API Change v2] --> E[v1 Still Works]
        E --> F[Clients Migrate Gradually]
        F --> G[Happy Users]
    end

Versioning Strategies

1. URL Path Versioning

The most common and visible approach:

GET /api/v1/users
GET /api/v2/users


// Express.js implementation
const express = require('express');
const app = express();

const v1Router = require('./routes/v1');
const v2Router = require('./routes/v2');

app.use('/api/v1', v1Router);
app.use('/api/v2', v2Router);

Pros : Clear, cache-friendly, easy to understand Cons : Duplicates route structure, longer URLs

2. Header Versioning

Version specified in request headers:

GET /api/users
Accept: application/vnd.myapi.v2+json


// Express.js middleware
function versionMiddleware(req, res, next) {
  const acceptHeader = req.headers['accept'] || '';
  const versionMatch = acceptHeader.match(/vnd\.myapi\.v(\d+)/);

  req.apiVersion = versionMatch ? parseInt(versionMatch[1]) : 1;
  next();
}

app.use(versionMiddleware);

app.get('/api/users', (req, res) => {
  if (req.apiVersion >= 2) {
    return getUsersV2(req, res);
  }
  return getUsersV1(req, res);
});

Pros : Clean URLs, follows HTTP standards Cons : Hidden versioning, harder to test

3. Query Parameter Versioning

Version in query string:

GET /api/users?version=2

Pros : Simple implementation Cons : Can be cached incorrectly, feels hacky

4. Custom Header Versioning

Most flexible approach:

GET /api/users
X-API-Version: 2


function versionMiddleware(req, res, next) {
  req.apiVersion = parseInt(req.headers['x-api-version']) || 1;
  next();
}

Implementing Backward Compatibility

Strategy 1: Additive Changes Only

Safe changes that never break clients:

// v1 response
{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com"
}

// v2 response (additive - safe)
{
  "id": 123,
  "name": "John Doe",
  "email": "john@example.com",
  "profile": { // New field
    "avatar": "...",
    "bio": "..."
  }
}

Strategy 2: Response Transformation

Transform responses based on version:

// services/userTransformer.js
const transformers = {
  v1: (user) => ({
    id: user.id,
    name: user.fullName,
    email: user.email,
  }),

  v2: (user) => ({
    id: user.id,
    name: user.fullName,
    email: user.email,
    profile: {
      avatar: user.avatarUrl,
      bio: user.biography,
      joinedAt: user.createdAt,
    },
  }),
};

function transformUser(user, version) {
  const transformer = transformers[`v${version}`] || transformers.v1;
  return transformer(user);
}

Strategy 3: Dual-Write Pattern

Support both old and new fields during migration:

// Accept both formats during transition
app.post('/api/users', (req, res) => {
  const { name, fullName, firstName, lastName } = req.body;

  // Support legacy 'name' field and new 'firstName/lastName'
  const user = {
    fullName: fullName || name || `${firstName} ${lastName}`,
    firstName: firstName || name?.split(' ')[0],
    lastName: lastName || name?.split(' ').slice(1).join(' '),
  };

  // Save user...
});

Deployment Workflow

sequenceDiagram
    participant Dev as Development
    participant Stage as Staging
    participant Prod as Production
    participant Clients as API Clients

    Dev->>Stage: Deploy v2 alongside v1
    Stage->>Stage: Test both versions
    Stage->>Prod: Deploy v2 (v1 still active)

    Note over Prod,Clients: Transition Period
    Prod->>Clients: Announce v2 availability
    Clients->>Prod: Migrate to v2
    Prod->>Clients: Deprecation warning for v1

    Note over Prod: After migration deadline
    Prod->>Prod: Remove v1

DeployHQ Deployment Strategy

Side-by-Side Version Deployment

#!/bin/bash
# deploy.sh - Deploy new version alongside existing

VERSION=$1
DEPLOY_PATH="/var/www/api"

echo "Deploying API version $VERSION"

# Deploy new version code
rsync -avz --delete \
    --exclude 'node_modules' \
    --exclude '.env' \
    ./ "$DEPLOY_PATH/"

# Install dependencies
cd "$DEPLOY_PATH"
npm ci --production

# Run migrations (if needed)
npm run migrate

# Restart application
pm2 reload api

# Verify both versions work
echo "Testing v1..."
curl -sf http://localhost:3000/api/v1/health || exit 1

echo "Testing v2..."
curl -sf http://localhost:3000/api/v2/health || exit 1

echo "Deployment complete!"

Feature Flag for Gradual Rollout

// middleware/featureFlags.js
const flags = {
  useNewUserEndpoint: {
    enabled: process.env.NEW_USER_ENDPOINT === 'true',
    percentage: parseInt(process.env.NEW_USER_ENDPOINT_PERCENTAGE) || 0,
  },
};

function shouldUseFeature(flagName, userId) {
  const flag = flags[flagName];
  if (!flag || !flag.enabled) return false;

  // Percentage rollout based on user ID
  const hash = hashUserId(userId);
  return hash % 100 < flag.percentage;
}

// Usage in route
app.get('/api/users/:id', (req, res) => {
  if (shouldUseFeature('useNewUserEndpoint', req.params.id)) {
    return newGetUser(req, res);
  }
  return legacyGetUser(req, res);
});

For more on feature flags, see what are feature flags.

Deprecation Workflow

Deprecation Headers

// middleware/deprecation.js
const deprecatedEndpoints = {
  'GET /api/v1/users': {
    deprecatedAt: '2024-01-01',
    sunsetAt: '2024-06-01',
    replacement: 'GET /api/v2/users',
  },
};

function deprecationMiddleware(req, res, next) {
  const key = `${req.method} ${req.path}`;
  const deprecation = deprecatedEndpoints[key];

  if (deprecation) {
    res.set('Deprecation', `date="${deprecation.deprecatedAt}"`);
    res.set('Sunset', deprecation.sunsetAt);
    res.set('Link', `<${deprecation.replacement}>; rel="successor-version"`);

    // Log deprecation usage for monitoring
    console.warn(`Deprecated endpoint accessed: ${key}`, {
      clientIp: req.ip,
      userAgent: req.headers['user-agent'],
    });
  }

  next();
}

Consumer Communication

// Track API version usage
const versionUsage = {};

app.use((req, res, next) => {
  const version = req.apiVersion || 1;
  const client = req.headers['x-client-id'] || 'unknown';

  versionUsage[client] = versionUsage[client] || {};
  versionUsage[client][version] = (versionUsage[client][version] || 0) + 1;

  next();
});

// Endpoint to check usage
app.get('/internal/api-usage', (req, res) => {
  res.json(versionUsage);
});

Contract Testing

Ensure backward compatibility with contract tests:

// tests/contracts/v1.test.js
const { expect } = require('chai');
const request = require('supertest');
const app = require('../../app');

describe('API v1 Contract', () => {
  describe('GET /api/v1/users/:id', () => {
    it('returns expected v1 schema', async () => {
      const response = await request(app)
        .get('/api/v1/users/1')
        .expect(200);

      // v1 contract: must have these fields
      expect(response.body).to.have.property('id');
      expect(response.body).to.have.property('name');
      expect(response.body).to.have.property('email');

      // v1 contract: must NOT have v2 fields
      expect(response.body).to.not.have.property('profile');
    });
  });
});

describe('API v2 Contract', () => {
  describe('GET /api/v2/users/:id', () => {
    it('returns expected v2 schema', async () => {
      const response = await request(app)
        .get('/api/v2/users/1')
        .expect(200);

      // v2 contract: must have all fields
      expect(response.body).to.have.property('id');
      expect(response.body).to.have.property('name');
      expect(response.body).to.have.property('email');
      expect(response.body).to.have.property('profile');
      expect(response.body.profile).to.have.property('avatar');
    });
  });
});

DeployHQ Build Commands with Contract Tests

# Install dependencies
npm ci

# Run unit tests
npm test

# Run contract tests (critical for versioning)
npm run test:contracts

# Build
npm run build

OpenAPI Documentation

Keep documentation in sync with versions:

# openapi/v1.yaml
openapi: 3.0.0
info:
  title: My API
  version: 1.0.0

paths:
  /users/{id}:
    get:
      summary: Get user by ID (v1)
      deprecated: true
      responses:
        200:
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/UserV1'

# openapi/v2.yaml
openapi: 3.0.0
info:
  title: My API
  version: 2.0.0

paths:
  /users/{id}:
    get:
      summary: Get user by ID (v2)
      responses:
        200:
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/UserV2'

Version Sunset Checklist

flowchart TD
    A[Announce Deprecation] --> B[Add Deprecation Headers]
    B --> C[Monitor v1 Usage]
    C --> D{Usage Below Threshold?}
    D -->|No| E[Reach Out to Heavy Users]
    E --> C
    D -->|Yes| F[Send Final Warning]
    F --> G[Remove v1]
    G --> H[Update Documentation]

Automated Monitoring

// Monitor version usage and alert
async function checkVersionUsage() {
  const stats = await getVersionStats();

  // Alert if v1 usage is still high before sunset
  if (stats.v1.percentage > 5 && isWithinSunsetWindow()) {
    await sendAlert({
      type: 'version-sunset-warning',
      message: `v1 still has ${stats.v1.percentage}% traffic`,
      topClients: stats.v1.topClients,
    });
  }
}

// Run daily
setInterval(checkVersionUsage, 24 * 60 * 60 * 1000);

Best Practices Summary

Choose a versioning strategy and stick with it
Make additive changes whenever possible
Never remove fields without versioning
Add deprecation headers before removing endpoints
Run contract tests on every deployment
Monitor version usage to plan migrations
Communicate changes clearly to consumers
Provide migration guides for breaking changes
Set clear sunset dates and enforce them
Keep documentation updated for all versions

Getting Started

Ready to implement API versioning? Here's your checklist:

Choose your versioning strategy (URL path recommended)
Set up version routing
Implement response transformers
Add contract tests to your pipeline
Set up deprecation monitoring

For zero-downtime deployment strategies, see our guide on zero-downtime deployments.

Questions about API versioning? Contact support@deployhq.com or follow @deployhq.

Context7 Guide: Stop AI Hallucinations with Live Docs

DeployHQ — Mon, 02 Feb 2026 19:47:14 +0000

You ask your AI assistant to help you set up authentication with Supabase. It confidently generates a full implementation using createClient() with options that haven't existed for two major versions. You spend the next hour debugging code that looks correct but simply doesn't work.

Sound familiar?

This is the hidden tax of AI-assisted coding. LLMs are trained on data that's often a year or more out of date, and frameworks like Next.js, React, and Rails move fast. That helpful code suggestion might use deprecated methods, removed parameters, or entirely hallucinated APIs.

Context7 solves this problem by injecting current, version-specific documentation directly into your AI's context—so you get working code on the first try.

What Is Context7?

Context7 is an MCP (Model Context Protocol) server built by Upstash that acts as a bridge between your AI coding assistant and up-to-date library documentation.

When you include use context7 in your prompt, the server identifies which library you're asking about, fetches the latest official documentation, and injects the relevant code examples directly into the AI's context window.

The result? Your AI assistant bases its suggestions on actual current APIs rather than guessing from stale training data.

sequenceDiagram
    participant Dev as Developer
    participant AI as AI Assistant
    participant C7 as Context7 MCP
    participant Docs as Library Docs

    Dev->>AI: "Set up Supabase auth. use context7"
    AI->>C7: Resolve library: supabase
    C7->>Docs: Fetch current documentation
    Docs-->>C7: v2.x API reference + examples
    C7-->>AI: Inject version-specific context
    AI-->>Dev: Working code using current APIs

The Problem It Solves

AI coding assistants have a fundamental limitation: their knowledge comes from training data with a cutoff date. Libraries evolve constantly—APIs change, methods get renamed, entire patterns get deprecated.

Here's what happens without Context7:

Outdated code examples based on old training data
Hallucinated APIs that don't actually exist
Generic answers that don't match your specific library version
Wasted time debugging code that looked correct

With Context7, you get:

Version-specific documentation pulled from the source
Current code examples that actually work
Accurate method signatures and patterns
Working code on the first try

If you've been following our coverage of MCP servers for web developers, you'll recognise Context7 as one of the essential tools we recommend. Now let's look at why it matters for your development workflow.

Context7 in Action: Real Examples

The best way to understand Context7's value is to see it work. Here are scenarios where it shines.

Example 1: Next.js Middleware

Without Context7 , your AI might generate middleware using patterns from Next.js 12 or 13 when you're actually using version 15.

With Context7 :

Create a Next.js middleware that checks for a valid JWT in cookies
and redirects unauthenticated users to /login. use context7

Context7 fetches the current Next.js 15 middleware documentation and your AI generates code using the correct NextResponse patterns, proper matcher configuration, and current edge runtime APIs.

Example 2: Rails API Authentication

Set up JWT authentication for a Rails 7.2 API using the jwt gem,
including refresh token rotation. use context7

Instead of getting code that might work with older Rails versions, you get implementations that align with current Rails conventions and the latest jwt gem API—perfect for Rails applications you're deploying through DeployHQ.

Example 3: Supabase Database Queries

Implement a Supabase query that fetches all users with their
related posts, with pagination. use context7

Context7 ensures you're using the current Supabase JavaScript client methods, not deprecated patterns from v1.

Example 4: Version-Specific Documentation

Need documentation for a specific library version? Just mention it:

How do I configure TailwindCSS 4.0 with Vite? use context7

Context7 automatically matches the appropriate version and delivers relevant documentation.

How to Get Started

Setting up Context7 takes just a few minutes. It works with all major AI coding tools including Cursor, Claude Desktop, Claude Code, and VS Code with MCP-compatible extensions.

We've written a comprehensive step-by-step guide covering:

Prerequisites and installation for each client
Configuration for automatic invocation
Advanced usage with direct library references
Troubleshooting common issues

Read the full Context7 setup guide

Pro Tip: Automatic Documentation Fetching

One of the best features covered in our setup guide is configuring automatic invocation. Instead of typing use context7 every time, you can set up rules so your AI assistant automatically fetches current documentation for any library-related question.

This means you write prompts naturally:

Create a Stripe checkout session API route in Next.js 15 App Router

And Context7 kicks in automatically, ensuring the generated code uses current APIs.

Context7 and DeployHQ: The Complete Workflow

Here's where things get interesting for web developers who deploy regularly.

From Accurate Code to Production

Pairing Context7 with DeployHQ's automated deployments creates a streamlined development pipeline:

Write accurate code with Context7 : Generate working implementations on the first try using current APIs
Push to your repository : Commit your changes to GitHub, GitLab, or Bitbucket
Deploy automatically : DeployHQ detects the push and deploys to your server with zero downtime

This workflow eliminates two of the biggest time sinks in web development: debugging hallucinated AI code and manual deployment processes. For a deeper look at setting up this kind of pipeline, see our guide on building a CI/CD pipeline with DeployHQ.

Even Better with DeployHQ MCP

If you're using Claude Code or another MCP-compatible assistant, you can take this further with the DeployHQ MCP Server. Combine it with Context7 and you can:

Generate accurate code using current documentation
Trigger deployments directly from your AI assistant
Check deployment status and history
Roll back if needed—all without leaving your editor

It's the complete AI-powered development workflow we've been building towards.

Libraries Available on Context7

Context7 maintains documentation for thousands of libraries across all major programming languages:

JavaScript/TypeScript : Next.js, React, Vue, Svelte, Astro, Supabase, Firebase, Prisma, Tailwind CSS, Express, Fastify, Hono

Ruby : Ruby on Rails, Sidekiq, Devise, Pundit

Python : Django, FastAPI, Flask, SQLAlchemy, Pydantic

And many more —the library is community-contributed and constantly growing.

If your favourite library isn't available, you can submit it through Context7's project addition guide.

The Bottom Line

Context7 addresses one of the most frustrating aspects of AI-assisted coding: the constant uncertainty about whether generated code actually works with your library versions.

By injecting current, version-specific documentation into your AI's context, Context7 transforms your coding assistant from a sometimes-helpful tool into a reliable pair programming partner that always knows the current APIs.

The setup takes a few minutes. The payoff is immediate: working code on the first try, no more debugging hallucinated methods, and no more tab-switching to verify that functions still exist.

Combined with continuous deployment through DeployHQ, you get a development workflow where accurate code flows smoothly from your editor to production.

Next Steps

Read our full Context7 setup guide — Detailed installation instructions for every client
Explore our list of MCP servers for developers — Context7 plus five other essential tools
Try DeployHQ MCP Server — AI-powered deployment automation
Start your free DeployHQ trial — Automate your deployments in minutes

Frequently Asked Questions

Is Context7 free to use?

Yes, Context7 is free for personal and educational use. If you need higher rate limits or access to private repositories, you can get an API key from the Context7 dashboard. See our setup guide for configuration details.

Which AI coding assistants work with Context7?

Context7 works with any MCP-compatible client, including Cursor, Claude Desktop, Claude Code, VS Code (with Cline or similar extensions), Windsurf, and others. Check our setup guide for installation instructions for each client.

What programming languages does Context7 support?

Context7 supports libraries across all major languages including JavaScript/TypeScript, Ruby, Python, Go, Java, and more. The library database is community-contributed and constantly growing. You can browse available libraries at context7.com.

How is Context7 different from just pasting documentation into my prompt?

Context7 automatically identifies the relevant library, fetches version-specific documentation, and injects only the relevant code examples into your AI's context. This saves time and avoids hitting token limits with bloated documentation. It also ensures you always get current information rather than whatever you happened to copy.

Can I add my own library's documentation to Context7?

Yes! Context7 is community-driven. You can submit libraries through their project addition guide. Library maintainers can also claim and manage their own documentation.

Do I need to type use context7 every time?

No—you can configure automatic invocation so your AI assistant fetches documentation automatically for any library-related question. Our setup guide explains how to set this up for Cursor and Claude.

Does Context7 work offline?

No, Context7 requires an internet connection to fetch documentation from its servers. The MCP server runs locally, but it needs to reach the Context7 API to retrieve library docs.

Can I use Context7 with the DeployHQ MCP Server?

Absolutely. You can run multiple MCP servers simultaneously. Using Context7 alongside the DeployHQ MCP Server gives you accurate code generation plus deployment automation—all from your AI assistant.

Resources

Have questions about Context7 or deployment automation? Reach out to support@deployhq.com or find us on X @deployhq.

DEV Community: DeployHQ

Deployment Agents Compared: DeployHQ vs Buddy vs Octopus Deploy

How Deployment Agents Work

Architecture Comparison

DeployHQ Agent: One Tunnel, Any Protocol

Buddy Proxy Agent: SSH Tunnels Under the Hood

Octopus Deploy Polling Tentacle: Agent Per Machine

Side-by-Side Comparison

The Proxy Model vs the Per-Machine Model

Proxy Model (DeployHQ, Buddy)

Per-Machine Model (Octopus)

Which Model Fits?

Protocol Support

Security Comparison

Pricing

DeployHQ

Buddy

Octopus Deploy

Cost for a Typical Setup

When to Use Each Tool

Choose DeployHQ Agent When:

Choose Buddy Proxy Agent When:

Choose Octopus Deploy Polling Tentacle When:

Conclusion

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

Why FTP Deployments Break Down

What to Track in Git (And What to Ignore)

Recommended .gitignore for WordPress

What You Should Track

Setting Up Git for WordPress

Option A: Track Only Your Theme/Plugin

Option B: Track the Entire wp-content Directory

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

Method 1: Automated Deployments with DeployHQ

Step 1: Create a Project

Step 2: Add Your Server

Step 3: Configure Build Steps

Step 4: Add Post-Deployment SSH Commands

Step 5: Enable Automatic Deployments

Step 6: Use .deployignore

Method 2: GitHub Actions + SSH

Method 3: WP-CLI Deployment Scripts

Handling the Hard Part: Database Migrations

Strategy 1: WP-CLI for Core Updates

Strategy 2: Migration Plugins

Strategy 3: Custom Migration Scripts

What NOT to Do

Multi-Environment Setup

In DeployHQ

WordPress Configuration Per Environment

WordPress-Specific .deployignore Patterns

Common Mistakes to Avoid

When to Use Each Method

Get Started

AI Code Review as Your Last Line of Defense Before Deployment

The Gap in Traditional Code Review

What AI Code Review Catches

1. Security Vulnerabilities

2. Performance Regressions

3. Configuration Issues

4. Breaking Changes

Integrating AI Review into Your Deployment Pipeline

Pre-Deployment Checklist: AI Edition

Practical Implementation

Using AI Assistants for Manual Review

Sample AI Review Output

Building Automated AI Gates

What AI Review Doesn't Replace

Measuring AI Review Effectiveness

Getting Started Today

Week 1: Manual AI Reviews

Month 1: Standardised Process

Month 3: Automated Integration

Key Takeaways

Continue Reading

OpenTelemetry in Practice: Setting Up Metrics, Traces, and Logs for Your Applications

The Three Pillars — and Why You Need All of Them

Why OpenTelemetry Won

Getting Started: The Two Approaches

Zero-Code Auto-Instrumentation

Recommended `.gitignore` for WordPress