DEV Community: DeployHQ

Self-Host Vaultwarden (Bitwarden) on a VPS with Docker

DeployHQ — Tue, 07 Jul 2026 07:18:28 +0000

Vaultwarden is an open-source, Rust-rewritten implementation of the Bitwarden server. It speaks the official Bitwarden protocol, so every Bitwarden client (web, desktop, mobile, browser extensions, CLI) works against it unchanged — but you run it on your own server, store your own data, and stop paying $10 a month for premium features that the official Bitwarden Free tier holds back.

This guide takes you from a fresh VPS to a hardened Vaultwarden instance running at vault.yourdomain.com, with TLS, an admin panel, push notifications for mobile clients, and a backup strategy that doesn't lose your entire vault on a bad disk. It is opinionated about the production setup the official quickstart leaves out.

Why self-host Vaultwarden

The trade-off vs Bitwarden's hosted service is straightforward:

Cost. Bitwarden Free is genuinely useful but capped (no TOTP, no organization sharing, no premium reports). Bitwarden Premium is $10/year per individual or $40/year for families. Vaultwarden gives you all of those features — TOTP, attachments, emergency access, organizations, premium reports — for the cost of a $5 VPS.
Sovereignty. Your encrypted vault never leaves a server you control. Bitwarden's hosted service is highly trusted (zero-knowledge architecture, audited), but if no third party ever touches the encrypted blob is your bar, self-hosting is the only answer.
Performance and latency. A small VPS in your region serves the API faster than Bitwarden's transatlantic infrastructure. Mobile autofill feels snappier.
Single source for your team. Agencies and small companies often want a private vault without paying per-seat. Vaultwarden organizations cover that.

The trade-offs are also honest:

You operate it. Bitwarden handles backups, uptime, security patches, and key rotation. With Vaultwarden, that is on you.
No iOS app review parity. The mobile clients connect to your server fine, but you do not get Bitwarden's enterprise compliance attestations.
Backups are non-negotiable. Lose the SQLite or Postgres data file without backups and every password is gone. There is no recovery.

If you can commit to backups and a 30-minute monthly upgrade window, Vaultwarden is one of the highest-leverage self-hosted services you can run.

Why Docker

Vaultwarden ships an official Docker image (vaultwarden/server:latest) that the project itself recommends as the supported install path. The native binary install is documented but second-class — every release ships a Docker image first. The image is small (~50 MB), the data lives in a single mounted volume, and upgrades are a docker compose pull && docker compose up -d away.

If you have followed our self-host Paperclip with Docker, n8n on Alibaba Cloud Linux 3, or self-host Nextcloud on a VPS guides, the playbook here is identical — only the image and env vars change.

Prerequisites

A VPS with at least 1 vCPU and 1 GB RAM (Vaultwarden is genuinely lightweight). 25 GB SSD covers years of vault growth.
A domain or subdomain (vault.yourdomain.com) with DNS pointing to the VPS.
Docker Engine and the Compose plugin on the VPS — see the easiest way to deploy on a VPS for the broader setup pattern.
An SMTP service (Postmark, SendGrid, Amazon SES, or your provider) for invitations, password hints, and 2FA fallback emails. Free tiers are fine.
A reverse proxy on the VPS — we use Caddy in this guide. Concepts are covered in our reverse proxy 101.

Install Docker on a fresh Ubuntu VPS:

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER

Log out and back in for the group change to apply.

The Compose stack

Vaultwarden's official quickstart shows a one-line docker run. For production, the Compose file below adds Postgres (the SQLite default works but is not what you want for a multi-user setup), proper volume management, healthchecks, and an internal-only port binding so Caddy is the only thing on the public internet.

Create /opt/vaultwarden/docker-compose.yml:

services:
  vaultwarden:
    image: vaultwarden/server:1.32-alpine
    container_name: vaultwarden
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    environment:
      DOMAIN: "https://vault.${DOMAIN_BASE}"
      DATABASE_URL: "postgresql://vault:${DB_PASSWORD}@db:5432/vaultwarden"
      ADMIN_TOKEN: "${ADMIN_TOKEN}"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      WEBSOCKET_ENABLED: "true"
      SENDS_ALLOWED: "true"
      EMERGENCY_ACCESS_ALLOWED: "true"
      SMTP_HOST: "${SMTP_HOST}"
      SMTP_FROM: "${SMTP_FROM}"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "${SMTP_USERNAME}"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"
      LOG_LEVEL: "warn"
      EXTENDED_LOGGING: "true"
    volumes:
      - vw-data:/data
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:17-alpine
    container_name: vaultwarden-db
    restart: unless-stopped
    environment:
      POSTGRES_USER: vault
      POSTGRES_DB: vaultwarden
      POSTGRES_PASSWORD: "${DB_PASSWORD}"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U vault"]
      interval: 5s
      timeout: 5s
      retries: 10

volumes:
  vw-data:
  pgdata:

Three details worth flagging.

First, port 80 binds to 127.0.0.1, not 0.0.0.0. Without that prefix, Docker exposes Vaultwarden directly on the public internet, bypassing your ufw/firewalld rules. Caddy on the same host proxies inbound HTTPS to it.

Second, the image is pinned to a version tag (1.32-alpine), not :latest. With a password manager, the version that happened to be in the registry when Watchtower last ran is the wrong upgrade strategy. Pin and upgrade deliberately.

Third, SIGNUPS_ALLOWED: "false" is critical for any vault that lives on the public internet. Without it, anyone who finds the URL can register and start using your server's storage. Use INVITATIONS_ALLOWED: "true" and invite users via the admin panel.

Generate a strong ADMIN_TOKEN — this protects the admin panel at /admin:

openssl rand -hex 64

Vaultwarden recommends an Argon2-hashed token in 1.30+. Generate one with:

docker run --rm -it vaultwarden/server:1.32-alpine /vaultwarden hash

Paste the resulting $argon2id$... string into ADMIN_TOKEN (escape any $ if you put it in a shell-evaluated .env).

Save the secrets to /opt/vaultwarden/.env:

DOMAIN_BASE=yourdomain.com
DB_PASSWORD=$(openssl rand -hex 32)
ADMIN_TOKEN=<the argon2 hash from above>
SMTP_HOST=smtp.postmarkapp.com
SMTP_FROM=vault@yourdomain.com
SMTP_USERNAME=<your postmark token>
SMTP_PASSWORD=<your postmark token>

chmod 600 /opt/vaultwarden/.env. This file is the keys to the kingdom.

TLS via Caddy

Vaultwarden absolutely requires HTTPS. The Bitwarden clients refuse to connect over plain HTTP, and any password manager served over an unencrypted channel is malpractice anyway.

Install Caddy (see our Caddy/Nginx/Apache comparison for why we usually pick Caddy) and write /etc/caddy/Caddyfile:

vault.yourdomain.com {
    reverse_proxy 127.0.0.1:8080

    # WebSocket endpoint for live notifications
    @websockets {
        path /notifications/hub
    }
    reverse_proxy @websockets 127.0.0.1:8080

    encode gzip
    log {
        output file /var/log/caddy/vaultwarden.log
        format json
    }

    header {
        Strict-Transport-Security "max-age=63072000"
        X-Content-Type-Options "nosniff"
        X-Frame-Options "DENY"
        Referrer-Policy "no-referrer"
    }
}

sudo systemctl reload caddy. Caddy fetches a Let's Encrypt cert on first request and renews automatically.

Start the stack:

cd /opt/vaultwarden
docker compose up -d
docker compose logs -f vaultwarden

Visit https://vault.yourdomain.com. You should see the Bitwarden login screen.

First-run: create your account, lock the door

Because we set SIGNUPS_ALLOWED: "false", you cannot register via the public form. Two options:

Option A — temporarily allow signups. Set SIGNUPS_ALLOWED: "true", restart, register your account, then flip it back to false and restart again. Crude but quick.

Option B — invite yourself via the admin panel. Visit https://vault.yourdomain.com/admin, paste your ADMIN_TOKEN, click Users → Invite, enter your email. Click the link in the email and finish account setup.

Option B is the operationally clean version — admin invitations leave an audit trail, and you never have public signups enabled even briefly.

Once you're in, install the Bitwarden clients on your devices and configure the server URL (in the app, before logging in: Self-hosted environment → Server URL: https://vault.yourdomain.com). Your existing Bitwarden vault export imports cleanly via Tools → Import data.

Push notifications for mobile clients

Without push, your iOS and Android Bitwarden apps get vault changes by polling — which means stale data and slow autofill. To get real push:

Register for a free Bitwarden push subscription at bitwarden.com/host/ (the same form Bitwarden uses for self-hosted Bitwarden Server).
They email you installation_id and installation_key.
Add to .env:PUSH_ENABLED=true PUSH_INSTALLATION_ID=<your id> PUSH_INSTALLATION_KEY=<your key> PUSH_RELAY_URI=https://push.bitwarden.com
Restart Vaultwarden. Mobile clients now receive push notifications via Bitwarden's relay (your encrypted blobs never go through it; only the vault changed trigger does).

Backups: the part nobody covers

A Vaultwarden instance without backups is a time bomb. The single Postgres volume (pgdata) plus the vw-data volume (which holds attachments, the RSA keys, and the Sends store) ARE your vault. Lose them, lose everything.

Minimum viable backup:

#!/bin/bash
# /usr/local/bin/vaultwarden-backup.sh
set -euo pipefail

BACKUP_DIR=/var/backups/vaultwarden
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p "$BACKUP_DIR"

# Postgres dump
docker exec vaultwarden-db pg_dump -U vault vaultwarden | \
  gzip > "$BACKUP_DIR/db-$TIMESTAMP.sql.gz"

# Data volume (RSA keys, attachments, sends)
docker run --rm -v vaultwarden_vw-data:/data -v "$BACKUP_DIR:/backup" \
  alpine tar czf "/backup/vw-data-$TIMESTAMP.tar.gz" -C /data .

# Retain last 30 days
find "$BACKUP_DIR" -type f -mtime +30 -delete

Schedule it via cron at 0 3 * * *. Then ship the backups off-host — to S3, B2, or another VPS — using restic or rclone. A backup that lives only on the server it backs up is not a backup; it is a hostage situation waiting for a disk failure.

Test restoration once a quarter. The first time you discover your backup script silently failed for six months should not be the day your VPS dies.

Operational concerns

A few things worth setting up before you forget about the box:

Fail2ban for the admin panel and the login endpoint. Vaultwarden ships logs with explicit [ERROR][...login attempt failed] markers; the Vaultwarden wiki has a ready-made jail config. Without this, the /admin endpoint is a brute-force target.
Rotate ADMIN_TOKEN quarterly. Roll a new Argon2 hash, update .env, restart. Cheap, and it limits blast radius if the token leaks.
Disable WEBSOCKET_ENABLED only if you have to. It powers real-time vault updates across logged-in clients; turning it off is a noticeable downgrade.
Monitor disk on the data volume. Attachments and the Sends feature can grow over time. Set a df alert at 80% to avoid waking up to a full disk.
Patch on a schedule. Subscribe to the Vaultwarden releases feed. Pin to a specific patch tag (1.32.7-alpine), test upgrades on a staging VPS first, then promote.

Continuous deployment with DeployHQ

If you maintain a fork of the Vaultwarden repo (custom branding, patched defaults, additional adapters) or simply want every upgrade to be a git push instead of an SSH session, the same continuous-deployment pattern from our Paperclip walkthrough above applies:

Fork dani-garcia/vaultwarden (or just keep your docker-compose.yml and Caddyfile in a private deploy repo — for most users this is enough).
Connect the repo to DeployHQ and configure a Docker build environment — or skip the build and have DeployHQ deploy only the compose file via SSH.
Add the VPS as an SSH server.
Deploy command: docker compose -f /opt/vaultwarden/docker-compose.yml --env-file /opt/vaultwarden/.env pull && docker compose -f /opt/vaultwarden/docker-compose.yml --env-file /opt/vaultwarden/.env up -d.
Push to your production branch when you want to upgrade. Vaultwarden 1.32.6 → 1.32.7 is now a git push away, with the upgrade visible in DeployHQ's audit log.

Wrapping up

You now have Vaultwarden on a VPS with TLS, admin panel access, push notifications, and a backup strategy that survives a disk failure. For under $10/month in VPS plus SMTP costs, you have an unlimited-user Bitwarden-compatible password manager that nobody else can read or revoke.

If you're running this for a small team or family, start a free DeployHQ trial so the next Vaultwarden upgrade is a git push instead of an SSH session. Pricing is on the plans page; the agency plan covers running Vaultwarden plus a dozen other self-hosted apps across multiple client VPSes.

Questions about Vaultwarden, backup strategy, or wiring up automated upgrades? Email us at support@deployhq.com or ping @deployhq on X.

How to Let AI Query Your Database Without Deleting It: Read-Only Guardrails for Claude Code

DeployHQ — Mon, 06 Jul 2026 09:04:36 +0000

A story made the rounds recently that put a chill down the spine of every developer experimenting with AI coding tools: someone gave an AI assistant live access to a production database, asked it to help clean things up, and watched it issue destructive commands that wiped real data. The specifics vary depending on who's telling it, but the shape of the story is always the same — an autonomous agent, a real connection string, write permissions, and no seatbelt.

Here's the uncomfortable truth: the AI wasn't malfunctioning. It did exactly what it was designed to do — generate and execute a plausible-looking command to accomplish the goal it was given. The failure wasn't the model. The failure was the access. We handed a probabilistic text generator the same keys we'd hesitate to give a brand-new junior engineer on their first day, and then acted surprised when it used them.

The good news is that this is an entirely solvable problem, and the solution isn't never let AI touch your database. AI is genuinely useful for exploring schemas, drafting queries, and debugging slow reports. The fix is to make destructive actions impossible, not just discouraged. This guide walks through the concrete guardrails — real GRANT statements, MCP-layer flags, sandbox patterns, and connection scoping — that let an AI query your database all day long without ever being able to delete it.

Why write access to prod goes wrong

Before the recipe, it's worth being precise about the failure mode, because the AI went rogue is the wrong mental model and leads to the wrong fixes.

When you connect an AI coding assistant to a database — usually through a Model Context Protocol server that bridges the model and your data — the model doesn't understand your data the way you do. It pattern-matches. Ask it to remove the test accounts and, if the connection it's been handed can run DELETE and DROP, it may generate a statement that's syntactically valid, semantically reasonable-looking, and catastrophically wrong: a missing WHERE clause, a TRUNCATE on the wrong table, a schema-altering migration it invented on the spot.

Three factors compound the risk:

Autonomy. Agentic tools chain actions together. A single prompt can trigger a sequence of tool calls with no human confirming each SQL statement before it runs.
Confidence without comprehension. The model has no model of this data is irreplaceable. It weighs a DROP TABLE the same way it weighs a SELECT.
Overprivileged connections. Most developers connect using their personal credentials or the app's connection string — both of which typically carry full read/write/DDL rights.

Fix the third factor and the first two stop mattering. If the connection physically cannot execute a DELETE, it does not matter how confidently the AI generates one. That's the principle everything below is built on.

The read-only principle: dedicated roles, not shared credentials

The single highest-leverage guardrail is also the oldest one in the database security playbook: give the AI its own database role, and grant that role only SELECT. No INSERT, no UPDATE, no DELETE, no DROP, no DDL. If the tool's only job is to read and analyze, it never needs anything else.

This is defense the database itself enforces. It doesn't rely on the AI behaving well, on a system prompt being obeyed, or on a middleware layer catching a bad command. The permission simply isn't there.

Here's the recipe for each of the big three.

PostgreSQL — create a login role, grant connect and read, and (critically) set default privileges so future tables are covered too:

-- 1. Create a dedicated, least-privilege login role
CREATE ROLE ai_readonly WITH LOGIN PASSWORD 'use-a-strong-secret-from-your-vault';

-- 2. Allow it to connect and read the schema
GRANT CONNECT ON DATABASE myapp TO ai_readonly;
GRANT USAGE ON SCHEMA public TO ai_readonly;

-- 3. Grant SELECT on all *existing* tables
GRANT SELECT ON ALL TABLES IN SCHEMA public TO ai_readonly;

-- 4. Make sure tables created *later* are also readable (this is the step people forget)
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO ai_readonly;

The ALTER DEFAULT PRIVILEGES line matters: without it, the AI role silently loses visibility every time you add a table, and someone fixes it later by granting something broader. Lock it down once, correctly.

MySQL / MariaDB — the same idea, scoped to SELECT only:

CREATE USER 'ai_readonly'@'%' IDENTIFIED BY 'use-a-strong-secret-from-your-vault';
GRANT SELECT ON myapp.* TO 'ai_readonly'@'%';
FLUSH PRIVILEGES;

Because GRANT SELECT ON myapp.* is scoped at the database level, it automatically applies to tables you create later — no default-privileges dance required. Tighten the host portion ('ai_readonly'@'10.0.%') to your network rather than '%' wherever you can.

SQL Server — this one is almost too easy, because it ships with a built-in role for exactly this purpose:

CREATE LOGIN ai_readonly WITH PASSWORD = 'use-a-strong-secret-from-your-vault';
CREATE USER ai_readonly FOR LOGIN ai_readonly;

-- db_datareader = SELECT on every current and future table in the database
ALTER ROLE db_datareader ADD MEMBER ai_readonly;

db_datareader grants SELECT on all user tables and views, current and future, and nothing else. It's the SQL Server answer to read everything, change nothing.

Whatever engine you're on, verify the guardrail the fun way: connect as the new role and try to break something. Run a DELETE or a DROP. You want a permission-denied error. If you get one, the AI will too — and no prompt injection, no hallucinated migration, no missing WHERE clause can get past it.

Setting up a least-privilege role is a one-time job that pays off every time an AI — or a script, or a new hire — touches your data. If you're already thinking about who can change what and when, that same discipline belongs in your deployment process: DeployHQ's build pipelines let you gate exactly which commands run against an environment, so schema changes go through review instead of an ad-hoc terminal session. More on that below.

Guardrails at the MCP layer

The read-only role is your backstop. The MCP server is your second line of defense, and it's worth configuring even when the role is already locked down — belt and suspenders.

Most AI database access flows through an MCP server that translates the model's requests into real queries. If you're new to the pattern, our complete guide to building an MCP server covers how these bridges work, and our roundup of the best MCP servers for web developers covers the ecosystem. For databases specifically, DBHub is a common choice, and it exposes two flags that matter here:

--readonly — DBHub refuses to execute any query that isn't a read. Even if the AI generates a DELETE, the server rejects it before it reaches the database. This is a software-layer mirror of your read-only role, and having both means a misconfiguration in one doesn't expose you.
--max-rows — caps the number of rows any single query can return. This defends against a different failure: not destruction, but a runaway SELECT * FROM events on a billion-row table that pins your database's CPU and memory. Set a sane ceiling (a few thousand rows) so an over-eager query degrades gracefully instead of taking prod down.

A typical hardened DBHub invocation looks like this:

dbhub --transport stdio \
  --dsn "postgres://ai_readonly:...@db-host:5432/myapp?sslmode=require" \
  --readonly \
  --max-rows 5000

Note the DSN uses the ai_readonly role from the previous section, not your admin credentials. The flags and the role reinforce each other. (DBHub's flags are documented in the DBHub repository — worth reading before you wire it up.)

If you're running this inside Claude Code, the Claude Code cheatsheet is a handy reference for the CLI flags and permission settings you'll touch while setting this up.

The sandbox pattern: give it a copy it can't hurt

Read-only access covers the vast majority of what you'd actually want an AI to do with a database — explore, analyze, draft queries. But sometimes you genuinely need it to write: test a migration, populate seed data, validate that a DELETE does what you expect. For anything destructive, the rule is simple: never do it against a database you care about.

The pattern is a disposable copy:

Snapshot or restore a copy of the relevant data into a throwaway database — a local container, an ephemeral schema, or a restored backup on a scratch instance.
Point the AI at the copy. Give it a full read/write role on that copy only. Now it can DELETE, TRUNCATE, and ALTER to its heart's content.
Throw it away when you're done. Nothing the AI did touched production.

A Docker-based scratch database is the fastest version of this:

# Spin up a disposable Postgres the AI can freely mutate
docker run --rm -d --name ai-sandbox \
  -e POSTGRES_PASSWORD=sandbox \
  -p 5433:5432 postgres:16

# Load a sanitized dump into it
pg_restore -h localhost -p 5433 -U postgres -d postgres ./sanitized-dump.dump

Two things make this safe rather than just convenient. First, the --rm flag means the container — and everything the AI did to it — evaporates when you stop it. Second, and non-negotiable for anything derived from production: sanitize the dump. Strip or mask PII before it lands anywhere an AI (and, via the model provider, potentially a third party) can read it. A sandbox that leaks real customer data isn't a safe sandbox.

A file-based engine makes this pattern even cheaper: with a local SQLite database, a disposable copy is a single cp command — you experiment where undo is free, then promote.

Connection scoping: SSH tunnels, TLS, and env-not-config

Even a perfectly permissioned read-only role is a liability if the credentials leak or the connection is exposed. Scope the connection itself.

Don't expose the database to the internet. The AI tool should reach your database over an SSH tunnel or a private network, not a publicly routable port. An SSH tunnel forwards a local port through an authenticated, encrypted channel:

# Forward local :5432 to the DB, reachable only via the bastion host
ssh -L 5432:db-internal:5432 deploy@bastion.example.com -N

Then point the AI at localhost:5432. The database's real port never faces the public internet. If you're already comfortable running deploy commands over SSH, this will feel familiar — our SSH commands reference covers the connection patterns.

Require TLS. Encrypt the connection so credentials and query results can't be sniffed in transit. In Postgres that's ?sslmode=require (or stricter — verify-full — if you've got the CA set up) on the DSN; MySQL and SQL Server have equivalents.

Keep credentials in the environment, not in config files. This is where a lot of otherwise-careful setups fall down. A connection string with a password committed to a mcp.json, a .env that's accidentally tracked, or a config file synced to a dotfiles repo is a credential leak waiting to happen. Reference secrets from environment variables or a secrets manager, and make sure the config that does get committed contains only variable references:

// good: no secret in the file
{ "dsn": "${DATABASE_URL_READONLY}" }

If you're setting up Claude Code for the first time, our getting-started guide for the terminal AI assistant walks through where its config lives and how to keep secrets out of it.

Guardrails are worth setting up once and reusing everywhere. If you'd rather your infrastructure enforce these boundaries by default — scoped credentials, encrypted connections, reviewed changes — that's exactly the discipline DeployHQ's deployment features are built around. Wire your database changes into a pipeline instead of a prompt.

Where deploys fit: schema changes belong in a pipeline

Here's the part most AI database safety advice skips entirely. Once you've locked the AI down to read-only, a fair question is: how do the actual, intended changes get made? Schema migrations, new indexes, column additions — those still need to happen.

The answer is emphatically not temporarily grant the AI write access and let it run the migration over SSH. That reintroduces every risk you just eliminated, plus a new one: an unreviewed, unlogged, unrepeatable change to production with no rollback path.

Schema changes belong in a reviewed build pipeline , the same way application code does. The migration is written (with the AI's help, drafting against a sandbox is great) and committed to version control. It's reviewed by a human. It runs as a deploy step, in order, with the change logged and the previous state recoverable. This is exactly the model in our guide to database migration strategies for zero-downtime deployments, and the broader practice of making database deployments repeatable and reversible.

The contrast is stark:

Ad-hoc AI SSH session	Reviewed deploy pipeline
Runs immediately, no review	Human reviews before it runs
No record of what changed	Every change logged
No rollback	One-click rollback to the prior state
Runs as an over-privileged user	Runs as a scoped deploy identity
Not repeatable across environments	Same migration, staging then prod

When a schema change is a version-controlled, reviewed deploy step, the fact that an AI helped write it is no longer scary — because the AI never executed it against prod. A human did, through a system built to make that action safe, observable, and reversible. Rolling migrations into a broader zero-downtime deployment strategy means even the intended changes never take the site down.

This is the whole philosophy in one line: let AI draft, let a pipeline deploy.

The copy-paste safety checklist

Print this, pin it, run through it before you connect any AI tool to any database that has data you'd miss.

AI + DATABASE ACCESS — SAFETY CHECKLIST

ROLE
[] AI connects via a DEDICATED database role, not personal or app credentials
[] That role has SELECT only — no INSERT/UPDATE/DELETE/DROP/DDL
[] Postgres: ALTER DEFAULT PRIVILEGES set so future tables stay read-only
[] SQL Server: role added to db_datareader (nothing broader)
[] Verified by connecting as the role and confirming DELETE/DROP is denied

MCP LAYER
[] MCP server (e.g. DBHub) launched with --readonly
[] --max-rows set to a sane ceiling to prevent runaway result sets
[] DSN uses the read-only role, never admin credentials

DESTRUCTIVE WORK
[] Any write/migration testing happens on a DISPOSABLE copy, never prod
[] Copies are PII-sanitized before the AI can read them

CONNECTION
[] Database is NOT exposed on a public port (SSH tunnel or private network)
[] TLS/SSL required on the connection (sslmode=require or stricter)
[] Credentials live in env vars / secrets manager, NOT in committed config

DEPLOYS
[] Schema changes go through a reviewed, version-controlled pipeline
[] No temporary write grants for "just this one migration"
[] Every change is logged and has a rollback path

Work down that list and the viral horror story simply can't happen to you. Not because your AI is smarter or better-behaved than the one in the story — but because you removed its ability to do harm in the first place. That's what security by design looks like: the safe path is the only path available.

This is the first article in our series on working safely with AI and databases, with companion deep-dives on MySQL-specific connection gotchas and a disposable-file SQLite workflow to follow.

Ready to move database changes out of ad-hoc terminal sessions and into a reviewed, reversible pipeline? Start deploying with DeployHQ for free and give your schema changes the same guardrails you just gave your AI.

Questions or want to share how you've locked down AI database access? Email us at support@deployhq.com or find us on X at @deployhq.

DeployHQ Static Hosting vs Cloudflare Pages: Same Edge, Different Workflows

DeployHQ — Fri, 03 Jul 2026 05:38:32 +0000

Choosing between DeployHQ Static Hosting and Cloudflare Pages is unusual in this category — both products serve your static site from the same Cloudflare edge network. The HTML, CSS, JavaScript, and images travel through the same 305+ POPs, get cached the same way, and exit at the same latencies. So the comparison isn't about CDN performance. It's about everything that happens before the file lands on the edge — the build pipeline, what else you can deploy from the same project, and how tightly you want to be coupled to the Cloudflare ecosystem.

This guide compares the two head to head: where the products diverge despite the shared edge, current pricing, and when to pick which.

TL;DR

If you're already deep in the Cloudflare stack — Workers for compute, R2 for object storage, KV for caching, D1 for SQL, Cloudflare DNS — Cloudflare Pages is the obvious answer. The native integration is excellent and the free tier is unusually generous (unlimited bandwidth, unlimited static requests).

If you also deploy backend code somewhere other than Cloudflare (a Laravel API on a VPS, a Rails app on a managed server, a WordPress install on shared hosting), DeployHQ Static Hosting puts the static site on the same Cloudflare edge that Pages uses while the same DeployHQ project ships your backend code to wherever it actually runs. One pipeline, one billing relationship, no Cloudflare lock-in for the parts of your stack that don't belong there.

For broader context across the category, our roundup of the best software deployment tools in 2026 covers Cloudflare Pages, DeployHQ, Vercel, and Netlify alongside the wider toolset. For the direct head-to-heads against the other edge hosts, see DeployHQ Static Hosting vs Vercel and DeployHQ Static Hosting vs Netlify.

At a glance: feature comparison

Capability	DeployHQ Static Hosting	Cloudflare Pages
Edge network	Cloudflare's global edge	Cloudflare's global edge (same network)
Framework auto-detection	Yes (rule + AI fallback)	Yes
Atomic deploys	Yes	Yes
Custom domains + SSL	Yes (automatic)	Yes (automatic)
Free tier bandwidth	Trial site included	Unlimited bandwidth (all tiers)
Build minutes	Bundled with DeployHQ plan	500/month Free, 5,000/month Pro
Concurrent builds	1 (parallelism via separate projects)	1 Free, 5 Pro, 20 Business
SPA mode (client-side routing)	Yes (toggle)	Yes (`_redirects` or `_routes.json`)
Server-side rendering	No (static only)	Limited via Workers (Pages Functions)
Edge functions	No	Yes (Pages Functions, Workers-based)
Native integrations	DeployHQ deployment pipeline	Workers, R2, KV, D1, Queues, AI
Backend deploys in same pipeline	Yes (VPS, shared host, cloud, S3)	Workers / Pages-only
Pricing model	Fixed monthly per site	Free / $20/mo Pro / $200/mo Business
Lock-in level	Low (artifact moves anywhere)	Medium (Pages Functions ↔ Workers tied)

Same edge. Different everything else.

When DeployHQ Static Hosting is the right choice

You already deploy a backend with DeployHQ — or are planning to. This is the strongest case. If you're shipping a static site plus a Laravel/Rails/Node backend, having both in one DeployHQ project means one set of deploy keys, one rollback surface, one billing relationship. The same workflow that ships your Hugo marketing site can ship your Express API to a DeployHQ Managed VPS — or to your own Hetzner box, or to shared hosting, depending on what fits. Cloudflare Pages can only deploy to Cloudflare; everything outside the Cloudflare ecosystem still needs a separate deployment workflow.

You want the same DeployHQ pipeline running your build. DeployHQ's build pipeline is intentionally generic — install dependencies, run tests, compile assets, set environment variables, run pre-deploy hooks. The build step doesn't care whether the destination is Static Hosting, a VPS, or an S3 bucket. If you've already tuned that pipeline for your project, deploying to Static Hosting requires no changes to it. See the SvelteKit deployment guide for a representative pipeline example.

You want predictable per-site pricing. Cloudflare Pages' free tier is the most generous in the category — unlimited bandwidth, unlimited static requests. That's hard to beat for a hobby project. But the Pro tier ($20/mo annual, $25/mo monthly) caps build minutes at 5,000/mo and concurrent builds at 5; Business jumps to $200/mo. DeployHQ Static Hosting charges a fixed monthly rate per site on top of your DeployHQ plan — useful when you're running multiple client sites and want a flat per-site cost regardless of build complexity. Compare current DeployHQ plans for the full breakdown. For broader trade-offs across hosting models, our shared hosting vs VPS guide for junior developers covers the wider category.

You want low lock-in. Pages Functions are written in the Workers runtime — if you migrate away, you rewrite them. DeployHQ Static Hosting serves a generic build artifact; if you ever want to leave, your build still produces the same files and works anywhere else that serves static content.

When Cloudflare Pages is the right choice

You're all-in on the Cloudflare stack. Workers for compute, R2 for object storage, KV for caching, D1 for SQL, Queues for messaging — Cloudflare Pages is the natural front door to that ecosystem. Direct bindings to Workers, R2, and KV from Pages Functions remove a lot of glue code. If your architecture is everything on Cloudflare, Pages is the lowest-friction static-hosting choice you can make.

You need the free tier specifically. Pages' free tier with unlimited bandwidth and unlimited static requests is unique in this category. For high-traffic hobby projects, marketing pages with viral spikes, or open-source documentation sites, that pricing structure can't be matched. DeployHQ Static Hosting doesn't have a directly comparable free forever tier — the trial includes a site and paid plans start from there.

You want Pages Functions for per-request logic. Geo-routing, A/B testing at the edge, authentication, header manipulation, simple APIs — Pages Functions running on Workers handles those cleanly. DeployHQ Static Hosting doesn't run code at request time; you'd put Cloudflare Workers in front of it to get the same behavior (which works, but isn't bundled).

You're not deploying anything outside Cloudflare. If your entire architecture lives in Cloudflare's ecosystem and you don't have backend services on VPS, shared hosting, or cloud platforms that DeployHQ would otherwise handle, the workflow-consolidation argument for DeployHQ doesn't apply. Stay on Pages.

Pricing: side by side

As of June 2026 — check vendor pages for current numbers.

Cloudflare Pages Free is $0 with 1 concurrent build, 500 builds/month, 100 custom domains per project, unlimited bandwidth, unlimited static requests. Genuinely the most generous free tier in the category.

Cloudflare Pages Pro is $20/month annual or $25/month monthly with 5 concurrent builds, 5,000 builds/month, 250 custom domains per project, unlimited bandwidth, unlimited static requests.

Cloudflare Pages Business is $200/month annual or $250/month monthly with 20 concurrent builds, 20,000 builds/month, 500 custom domains per project.

DeployHQ Static Hosting charges a fixed monthly rate per site, shown on the Hosted Resources page in your account's currency. Pricing rolls into your DeployHQ plan on a single monthly invoice. Trial accounts can provision one Static Hosting site at no charge.

The honest framing: for a single static site with no backend, Cloudflare Pages Free is structurally cheaper than any DeployHQ tier because Free is $0. The DeployHQ math gets favorable when you're already paying for DeployHQ to deploy backend code somewhere — at that point the static site is bundled into a plan you're already running, and the marginal cost of adding Static Hosting is the per-site rate, not a new vendor relationship.

Moving between them (it's not all-or-nothing)

Both platforms serve the same static artifact, so migration in either direction is mostly DNS plus repo reconfiguration.

From Cloudflare Pages to DeployHQ Static Hosting: connect the repository in DeployHQ, point Static Hosting at the same build output directory Pages used, keep the build command identical, switch DNS once verified. If you depend on Pages Functions, plan replacements first — Cloudflare Workers in front of Static Hosting can serve the same role, but you maintain them separately rather than co-located with the static project.

From DeployHQ Static Hosting to Cloudflare Pages: even simpler — connect the repo to Pages, set the same build command and output directory, switch DNS. Nothing DeployHQ-specific in your code to unwind.

Or: use both. Run your static frontend on Cloudflare Pages, keep DeployHQ as your deployment pipeline for the backend you ship to a VPS or shared host. This combination is common — Pages handles the frontend exceptionally well, DeployHQ handles everything else. The trade-off is two deployment surfaces instead of one; whether that's worth it depends on how much your team values consolidation.

For broader background on legacy hosting and modern alternatives, is FTP dead? covers the wider shift in deployment patterns.

The shared-edge dimension

Both products use Cloudflare's edge. In practice this means:

Latency : identical from a given user's location. There's no advantage to either product on raw edge performance for static content.
DDoS protection : included on both via Cloudflare's standard protection.
HTTPS certificates : provisioned automatically by Cloudflare in both cases.
Cache invalidation : works at deploy time (atomic deploys flip the served version) in both products.

What's different despite the shared edge:

Cloudflare account requirement : Pages is part of your Cloudflare account; you log in there, your billing lives there, your custom domains route through Cloudflare DNS. Static Hosting doesn't require a Cloudflare account — it manages the Cloudflare infrastructure on your behalf.
Workers bindings : Pages Functions can bind directly to Workers, R2, KV, D1, Queues. Static Hosting doesn't expose these bindings — if you need them, you front the Static Hosting site with your own Worker that has the bindings.
Pre-edge build pipeline : DeployHQ's build runs on DeployHQ's servers with its own pipeline UI, env-var management, and rollback history. Cloudflare Pages runs builds on Cloudflare's infrastructure with its own UI. They produce the same artifact but the pre-edge experience differs.

DeployHQ also exposes one-click rollback — useful when you ship something broken and need to revert without rebuilding. Pages supports a similar flow through its deployment history UI, but the DeployHQ rollback is the same one-click motion you'd use for a Managed VPS deploy or a BYO-server deploy. One mental model across all targets.

FAQ

Are there any latency differences between DeployHQ Static Hosting and Cloudflare Pages?No. Both serve from Cloudflare's global edge network. Latency to a given user depends on their geography and the nearest Cloudflare POP — which is identical for both products.

Does DeployHQ Static Hosting use my own Cloudflare account?No. DeployHQ manages the Cloudflare infrastructure on your behalf. You don't need a Cloudflare account to use Static Hosting; subdomains under deployhq-sites.com work out of the box, and custom domains use a CNAME from your DNS provider.

Can I use Cloudflare Workers in front of DeployHQ Static Hosting?Yes. If you need edge-function behavior (geo-routing, edge auth, request rewriting), set up a Cloudflare Worker on your custom domain that proxies to your Static Hosting subdomain. The Worker runs at the edge with full Worker capabilities.

What about Hugo, Astro, Eleventy, and other static-site generators? Both products support all major static-site generators since they serve the build artifact, not the source. See the Hugo deployment guide for a representative DeployHQ pipeline example.

What if I outgrow Static Hosting and need a runtime? Move the project to DeployHQ Managed VPS Hosting (for full Linux + Node/Python/Ruby), or front Static Hosting with Cloudflare Workers for lightweight edge logic. Same DeployHQ pipeline ships to either target.

Get started

If you're already on DeployHQ, enable beta features under Settings > Beta Features and add a new Static Hosting server to any project. The Static Hosting on DeployHQ pillar guide walks through the end-to-end provisioning flow.

If you're new, start a free trial and the included Static Hosting site lets you compare it head-to-head against Cloudflare Pages for the same project. For the wider picture of where Static Hosting fits among the five hosting types DeployHQ supports, see your universal deployment and hosting platform.

Both DeployHQ Static Hosting and Cloudflare Pages serve from the same edge, and both do the static-hosting job well. The right answer depends almost entirely on what's around your static site. If your stack is all-Cloudflare, Pages wins on integration and free-tier economics. If you also ship backend code outside Cloudflare — and especially if you want one deployment pipeline for the whole stack — DeployHQ Static Hosting wins on workflow consolidation.

For more detail on the product, the Static Hosting support library has the full provisioning, framework-detection, and lifecycle documentation.

Questions or feedback on Static Hosting vs Cloudflare Pages? Email support@deployhq.com or follow @deployhq on X for product updates.

Free Static Hosting for v0, Bolt, Lovable, and Firebase Studio Apps

DeployHQ — Tue, 30 Jun 2026 07:39:28 +0000

You describe an app in a chat window. Twenty seconds later you're staring at a working React UI that does roughly what you asked for. v0, Bolt, Lovable, and Firebase Studio have made the first hour of building a web app look almost magical — and the next hour is when reality lands. Where does this thing actually live? Whose name is on the URL? Who pays the bill?

The defaults each of these tools nudge you toward all share one trait: lock-in. v0 ships you to Vercel. Bolt has a one-click button to Netlify. Lovable hosts at <project>.lovable.app until you upgrade. Firebase Studio assumes Firebase Hosting. Each of those is a fine first step — they're free, they work in two clicks, they give you a URL to share. They also bind you to one ecosystem's pricing, runtime, and account terms the moment you want to move past the demo.

This isn't a hypothetical migration — it's a pattern users are already documenting. The r/lovable thread sorry Lovable, but I moved on is one recent example: OP and the top commenters describe the same workflow shift — keep the AI builder for the initial scaffold, then continue editing in your own editor with Claude Code or Cursor, with Supabase still doing the backend, and free hosting on top. That last bullet is the one this post addresses. Most migrants land at Vercel because it's the most visible free option; this is the alternative.

DeployHQ Static Hosting is the lock-in-free alternative for the static frontend these tools produce. It runs on Cloudflare's global edge, framework-detects your build (Next.js, Vite, Astro, Angular, SvelteKit, Flutter web), and atomically deploys every Git push. It's free during beta. And it doesn't touch the backend you've already wired up — Supabase, Firebase, your own API, whichever the tool of your choice put behind your UI.

The pattern: where each AI builder leaves you

Builder	Default deploy target	What you can move	What you can't
v0	Vercel	The Next.js project (with static export configured)	Server actions, App Router server components, route handlers
Bolt	Netlify	Vite + React/Vue/Svelte, Astro, SvelteKit static, Next.js export	The `server/` directory in full-stack starters
Lovable	`*.lovable.app` (custom domains paid)	The Vite + React frontend	Custom Node servers you've added beyond Supabase Edge Functions
Firebase Studio	Firebase Hosting	Next.js export, Angular, Vite, Astro, Flutter web	Firebase App Hosting (Cloud Run SSR), `firebase.json` rewrites

The pattern: anything that compiles to a flat output directory — dist/, out/, build/ — moves cleanly to Static Hosting. Anything that needs a Node runtime at request time — server actions, SSR, route handlers, your own Express/Hono backend — doesn't, and shouldn't try to.

For the parts that don't fit static, DeployHQ Managed VPS is the upgrade path (covered in detail below). Same DeployHQ project, same build pipeline, different deploy target. You don't have to choose one or the other at the start.

The four how-to guides

Each of the tools has its own export flow, framework defaults, and a handful of gotchas worth knowing before the first push. Walk through whichever guide matches your starting point:

v0 : How to Deploy a v0 App to DeployHQ Static Hosting — covers exporting from v0 to GitHub, switching Next.js into static-export mode, and the server-action gotchas v0 sometimes generates.
Bolt : How to Deploy a Bolt App to DeployHQ Static Hosting — works across every framework Bolt scaffolds. Includes the WebContainer path-cleanup gotcha and the framework→output-directory mapping for Vite, Astro, SvelteKit, Next, and Remix.
Lovable : How to Deploy a Lovable Frontend to DeployHQ Static Hosting — keeps the Supabase backend intact and walks through updating Supabase Auth redirect URLs for the new domain. The static frontend, your Supabase backend keeps doing the work path.
Firebase Studio : How to Deploy a Firebase Studio App to DeployHQ Static Hosting — covers the framework-agnostic build configuration, the Firebase Auth authorized-domains update, and the carve-out around Firebase App Hosting.

All four follow the same shape: export to GitHub, point DeployHQ at the repo, configure the build pipeline with the right framework env-var prefixes, ship the first deploy, then update auth allowlists if the backend you're calling has one.

What stays the same when you move

The biggest reason people stall on moving an AI-built app off its default host is the worry that auth and data will break. They almost never do.

Supabase-backed projects (Lovable's default and a common pattern in v0/Bolt) keep working because Supabase's API and Auth flows are hosted on Supabase. You set VITE_SUPABASE_URL and VITE_SUPABASE_ANON_KEY in DeployHQ's environment-variable UI, add the new domain to Supabase's redirect-URL allowlist, and the rest is unchanged.
Firebase-backed projects (Firebase Studio's default, sometimes appears in other builders) keep working because Firebase Auth, Firestore, Storage, and Cloud Functions all run on Google's infrastructure. You add the new domain to Firebase Auth's authorized-domains list and the SDK keeps talking to the same backend it always did.
Apps calling third-party APIs directly (Stripe checkout, public REST APIs, scraped data sources) keep working because those calls leave the browser regardless of where the bundle is served from.

The only things that genuinely move are the build pipeline (now run by DeployHQ instead of Vercel/Netlify/Firebase) and the public URL (now Cloudflare's edge instead of Vercel/Netlify/Firebase Hosting). Everything between user and database stays put.

Why this is worth the 15 minutes

The first deploy from an AI builder's default host is essentially free. The second one — when the demo becomes a real project — is where the trade-offs start mattering:

Lock-in. Each builder's default host is owned by a different company. Moving later is harder than picking your own host up front, because URLs accumulate users, integrations, and SEO equity that don't migrate cleanly.
Pricing trajectory. Vercel's bandwidth and serverless-execution pricing scales with traffic. Netlify's build-minute caps bite earlier than you'd expect on a chatty Vite project — the DeployHQ Static Hosting vs Netlify comparison covers where those thresholds land. *.lovable.app is fine for demos but custom domains are a paid Lovable plan. Firebase Hosting traffic is metered against the same Firebase Spark/Blaze quotas as your database calls.
Runtime constraints you didn't agree to. Vercel's static export still goes through Vercel's edge-function billing model. Netlify's bandwidth tier resets monthly. Firebase Hosting can serve static files but pulls you into the broader Firebase plan structure.

DeployHQ Static Hosting is free during the beta, and the post-beta plan structure is straightforward enough to put on a single DeployHQ pricing page — covered in the same way the rest of the DeployHQ catalog is priced, with no per-invocation runtime metering on a static bundle.

For the head-to-head against the most common alternatives, read the DeployHQ Static Hosting vs Vercel comparison — it covers framework support, pricing, edge network, and the trade-offs that decide which one fits your stack. The Static Hosting pillar guide is the longer reference on framework auto-detection, SPA mode, atomic deploys, and the rest of the feature surface.

What Static Hosting isn't for

Three categories of project don't belong on Static Hosting, and it's worth saying so up front:

Anything with required SSR at request time. Next.js with server actions, Astro with server-side render, SvelteKit with the Node adapter, full Next.js App Router server components — these need a Node runtime Static Hosting doesn't provide. Move them to Managed VPS or refactor to static export.
Full-stack starter templates with bundled servers. Bolt's full-stack starters include an Express or Hono server. Lovable projects that have grown a custom WebSocket layer beyond Supabase Edge Functions. v0 projects you've turned into half-static, half-SSR hybrids. The static frontend half deploys fine; the server half needs to live somewhere with a runtime.
Firebase App Hosting projects. Firebase Studio's newer App Hosting target provisions a Cloud Run instance for SSR — that runtime is fundamentally Google-bound and can't move to Static Hosting.

In all three cases, DeployHQ Managed VPS is the natural home — same DeployHQ project, same Git workflow, different deploy target. You can also split the difference: keep the static UI on the edge and run only the dynamic parts on Managed VPS. The build pipeline you set up adapts to either target.

How to start

If you're already an AI-app-builder user with a project ready to move:

Pick the guide that matches your tool (v0, Bolt, Lovable, Firebase Studio — links above)
Export to GitHub if you haven't already
Sign up free for DeployHQ — the beta-tier Static Hosting site is included
Walk through the guide; the whole loop is under 20 minutes

If you're earlier in the journey and still deciding which builder to use, the framework support is the right way to choose: Static Hosting framework-detects every common output, so the question is really which builder's UX you prefer and which backend (Supabase, Firebase, your own) you want behind it. The hosting decision compounds: pick a lock-in-free host now and you keep the option to swap the builder later.

For the broader DeployHQ catalog beyond static, the hosting hub covers the four other deploy targets DeployHQ supports — Managed VPS, SFTP, SSH/Rsync, S3 — all driven from the same project and build pipeline. And for context on the proposition across the full hosting catalog, your universal deployment and hosting platform is the longer read.

The full product reference lives in the Static Hosting support library. And for a roundup of how DeployHQ fits alongside the rest of the deployment-tool category, best software deployment tools in 2026 is a useful next reference.

Questions, edge cases, or a builder you'd like covered that isn't in the list above? Email support@deployhq.com or follow @deployhq on X — we're adding to this list as more AI builders ship credible static-export paths.

How to Deploy a Firebase Studio App to DeployHQ Static Hosting

DeployHQ — Fri, 26 Jun 2026 14:11:37 +0000

DeployHQ Static Hosting serves pre-built static assets from Cloudflare's global edge — a clean fit for a Firebase Studio project, where Gemini Code Assist scaffolds a Next.js, Angular, or Vite-based frontend that builds to a flat output directory. This guide walks through deploying a Firebase Studio app end to end: sync the workspace to GitHub, configure the framework for static export, provision Static Hosting, set up the build pipeline, update Firebase Auth's authorized domains, and ship the first deploy.

The framing matters: Static Hosting replaces the Firebase Hosting URL Firebase Studio provisions by default, not the Firebase backend behind it. Firebase Auth still issues tokens. Firestore still stores data. Cloud Functions still run on Google's infrastructure. Static Hosting is the public face — a faster, lock-in-free home for the frontend bundle that calls all of it. The one exception: if you've enabled Firebase App Hosting (which provisions a Cloud Run instance for SSR), that runtime is bound to Google Cloud and can't move to Static Hosting. For static-export builds, you're good — keep reading.

What you'll build

By the end of this guide:

A Firebase Studio workspace synced to your own GitHub repository
A DeployHQ project with Static Hosting connected to that repo
A framework configured for static output (Next.js export, Vite build, Angular --configuration production, etc.)
A working build pipeline that runs your framework's build and uploads the output to Cloudflare's edge
Firebase Auth authorized domains updated to include the new URL
The site serving over HTTPS at <subdomain>.deployhq-sites.com (and optionally a custom domain)
Atomic deploys on every push to main, with one-click rollback to any previous version

Expected time: under 20 minutes from a Firebase Studio workspace you already have set up.

Prerequisites

A Firebase Studio workspace — created at firebase.studio — with a working frontend and a Firebase project providing whatever services it uses (Auth, Firestore, Storage, Functions)
A GitHub account you can sync the workspace to
Access to the Firebase project's console (you'll update Auth authorized domains in Step 7)
A DeployHQ account with beta features enabled (enable under Settings > Beta Features )
Node.js installed locally if you want to test the build before pushing (optional but recommended)

If you don't have a DeployHQ account yet, you can start a free trial in the next step — the trial includes one Static Hosting site at no charge while the feature is in beta.

Step 1: Sync your Firebase Studio workspace to GitHub

Firebase Studio runs your workspace in a Nix-based environment in the browser, with the source code stored in a Google Cloud workspace. To deploy on DeployHQ, the code needs to live in a normal Git repository.

In Firebase Studio:

Open the workspace you want to deploy
Open the Source Control panel from the left sidebar
Click Publish to GitHub (or Sync if you've already connected a repo)
Authorize Firebase Studio's GitHub integration if you haven't already
Choose a repository name and visibility, then publish

Firebase Studio commits the workspace contents — package.json, framework config files, src/, the dev.nix environment file under .idx/, and any Firebase configuration files (firebase.json, .firebaserc) — to the main branch of the new repository.

Open the repo in GitHub and confirm package.json is at the root. You'll identify the build command and output directory in the next step.

Step 2: Configure the framework for static output

Firebase Studio scaffolds projects across several frameworks. The right Static Hosting configuration depends on which template the workspace started from. Two things to verify: the build command and the output directory.

Framework	Default build command	Output directory	Static-ready out of the box?
Next.js (App Router)	`npm run build`	`out/`	No — set `output: 'export'` in `next.config.js`
Angular	`npm run build`	`dist/<project-name>/browser/`	Yes
Vite + React	`npm run build`	`dist/`	Yes
Vite + Vue	`npm run build`	`dist/`	Yes
Astro	`npm run build`	`dist/`	Yes
Flutter web	`flutter build web`	`build/web/`	Yes

For the Next.js case specifically, open next.config.js (or next.config.mjs) and add:

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
};

module.exports = nextConfig;

This switches Next.js from SSR mode to a static export written to out/. Any code path using getServerSideProps, server actions, route handlers, or App Router server components will fail the build — those features need a runtime Static Hosting doesn't provide. The images.unoptimized: true flag disables Next.js Image Optimization, which also needs a server.

If your workspace uses firebase.json to define Firebase Hosting rewrites — single-page-app fallbacks, URL redirects, custom headers — those won't apply on DeployHQ. SPA rewrite is handled by Static Hosting's SPA mode (Step 4), and Cloudflare's edge handles HTTPS and caching headers automatically.

Step 3: Verify the Firebase configuration

Firebase Studio apps initialize the Firebase JS SDK with a config object usually pulled from environment variables (NEXT_PUBLIC_FIREBASE_* for Next.js, VITE_FIREBASE_* for Vite, process.env.NG_APP_FIREBASE_* for Angular).

Open the Firebase initialization file (src/lib/firebase.ts, src/firebase.ts, or wherever your workspace puts it) and confirm it reads from environment variables rather than hardcoded values. The relevant variables are:

*_FIREBASE_API_KEY — public API key (safe in client bundles)
*_FIREBASE_AUTH_DOMAIN — typically <project-id>.firebaseapp.com
*_FIREBASE_PROJECT_ID
*_FIREBASE_STORAGE_BUCKET
*_FIREBASE_MESSAGING_SENDER_ID
*_FIREBASE_APP_ID

These are all designed to be public — Firebase enforces security at the service level via Firestore Security Rules, Storage Rules, and Firebase Auth, not by hiding the config.

If your project calls Cloud Functions, the function URLs use the Firebase project's default domain (https://<region>-<project-id>.cloudfunctions.net or https://<custom-domain>.cloudfunctions.net). Those calls work from any frontend host as long as the function's CORS is configured to allow your origin (covered in Step 7 and the gotchas section).

Step 4: Provision a Static Hosting site in DeployHQ

In your DeployHQ project (or create one and connect it to the Firebase Studio repository), click New Server :

Enter a name for the server — internal reference only, doesn't affect the public URL
Select Static Hosting from the protocol picker under Hosting
Choose a subdomain — your site serves at <subdomain>.deployhq-sites.com. Subdomains are unique across all DeployHQ accounts; lowercase letters, numbers, and hyphens only
Set the subdirectory to deploy from to match your framework's output directory from Step 2 (out/, dist/, dist/<project-name>/browser/, or build/web/)
Toggle SPA mode based on your framework:
- On for Angular, Vite + React/Vue SPAs, Flutter web — these use client-side routing and need unknown paths rewritten to index.html
- Off for Next.js static export and Astro — these generate one HTML file per route at build time
Click Create Server

DeployHQ runs framework detection against the connected repository. If a [Framework] detected! callout appears with a suggested output directory and SPA mode, the rule-based detector is doing the work for you. Accept the suggested values unless your framework config diverges from the defaults.

Provisioning takes under a minute. Once the status flips to active, the site exists on Cloudflare's edge — but no code has shipped yet.

Step 5: Configure the build pipeline

DeployHQ runs your build before transferring artifacts to the edge. For a Firebase Studio-exported project, the build pipeline is two stages: install, then build.

In the project's build settings, add:

npm ci
npm run build

For Flutter, swap to the Flutter SDK install + flutter build web instead. For Angular projects with environment-specific builds, you may need npm run build -- --configuration production.

Environment variables to set in DeployHQ's environment-variable UI — the prefix depends on your framework:

Next.js : NEXT_PUBLIC_FIREBASE_API_KEY, NEXT_PUBLIC_FIREBASE_AUTH_DOMAIN, etc.
Vite + React/Vue : VITE_FIREBASE_API_KEY, VITE_FIREBASE_AUTH_DOMAIN, etc.
Angular : NG_APP_FIREBASE_API_KEY etc. (or environment.ts files if you're using the older pattern)

What you should not put here: Firebase Admin SDK service-account JSON, Firebase Functions deployment tokens, any credential that grants server-side access. Those belong in Cloud Functions runtime config, never in a static bundle.

If your project also uses third-party services (Stripe publishable keys, Sentry DSN, public analytics IDs), they go here too — same prefix rules apply.

Ready to take it live? Sign up free for DeployHQ if you don't have an account, and the beta-tier Static Hosting site is enough to ship this guide end to end.

Step 6: First deploy

Push any change to the configured branch (typically main), or trigger a manual deployment from the DeployHQ dashboard. DeployHQ:

Clones the repo at the head of the configured branch
Runs the build pipeline (npm ci && npm run build)
Uploads the contents of your output directory to object storage atomically
Flips Cloudflare's edge routing to serve the new version

The deployment log streams each step in real time. When it completes, visit https://<subdomain>.deployhq-sites.com — the site loads, but Firebase Auth won't yet allow sign-ins from the new domain. That's Step 7.

If the build fails, the log shows the exact error. Most common failures for Firebase Studio projects:

A Next.js page or route handler using a server-only feature without output: 'export' configured
A missing *_FIREBASE_* env var the client bundle references at build time
A firebase.json declaring a Cloud Functions rewrite the static export can't fulfill
An Angular project building without the production configuration, leaving development-only checks in the bundle

Fix the issue in the repo, commit, push — DeployHQ runs the next build automatically.

Step 7: Update Firebase Auth authorized domains

Firebase Auth has an allowlist of authorized domains — sign-in flows only work from domains on that list. Until your new domain is added, OAuth providers (Google, Facebook, GitHub) and email-link sign-ins will reject the authentication request.

In the Firebase Console:

Open the project that backs this app
Navigate to Authentication > Settings > Authorized domains
Click Add domain and enter <subdomain>.deployhq-sites.com (and any custom domain you'll add in Step 8)
Save

Existing entries like localhost, your old Firebase Hosting domain, and any previously configured custom domains stay on the list — Firebase Auth allows multiple authorized domains, so the Firebase Studio preview environment continues to work.

Sign out, sign back in on the new domain, and confirm the auth flow round-trips correctly.

Step 8: Add a custom domain

To serve from your own domain (e.g., app.example.com):

In your DNS provider, add a CNAME record pointing your subdomain to <subdomain>.deployhq-sites.com
Wait for DNS propagation (usually minutes; depends on your TTL)
Cloudflare provisions an HTTPS certificate automatically once the CNAME resolves
Add the custom domain to Firebase Auth's authorized domains list (same path as Step 7) so OAuth flows from app.example.com round-trip correctly

Your site now serves from app.example.com over HTTPS via Cloudflare's edge, talking to the same Firebase backend Firebase Studio scaffolded for you.

For an apex domain (example.com with no subdomain), use an ALIAS or ANAME record if your DNS provider supports them — Cloudflare DNS, DNSimple, and Route 53 all do. Otherwise, host the apex elsewhere and CNAME a www subdomain to DeployHQ.

Common gotchas

Firebase Studio App Hosting isn't supported. Firebase App Hosting is Firebase's newer SSR offering — it provisions a Cloud Run instance per deployment. That runtime is fundamentally Google-bound. If your workspace was scaffolded for App Hosting, you're locked into Firebase Hosting until you switch to a static-export configuration. Static Hosting is for static export only.

OAuth provider rejects the new domain. Google sign-in, Facebook sign-in, GitHub sign-in, and other federated providers have their own allowlists in addition to Firebase Auth's authorized domains list. Open each provider's app/credentials page (Google Cloud Console, Facebook Developers, GitHub OAuth Apps) and add the new Firebase Auth callback URL — usually https://<project-id>.firebaseapp.com/__/auth/handler — to the authorized redirect URIs. The error usually shows up as a redirect_uri_mismatch in the provider's response.

Cloud Functions return CORS errors. Cloud Functions enforce origin allowlists. Update the function's CORS configuration (typically via the cors package in your function source, or via Firebase Hosting rewrites that proxy through firebase.json — which doesn't apply here). For DeployHQ-hosted frontends, configure CORS directly in the function code to accept your new domain.

Firestore queries return empty results in production. Almost always a Firestore Security Rules mismatch. The Firebase Studio preview environment sometimes uses a different auth context. Check the rules on the affected collections and confirm they allow the production user's auth claims.

Build succeeds but environment variables don't appear in the bundle. Each framework requires a specific prefix at build time: Next.js needs NEXT_PUBLIC_*, Vite needs VITE_*, Angular reads from a separate environment.production.ts file by default. Double-check (a) the variable names match the prefix exactly, (b) you triggered a new build after setting them, and (c) for Angular, you're building with the production configuration.

firebase.json rewrites don't apply. Firebase Hosting's rewrites array configures the SPA fallback, URL redirects, and Cloud Function proxying. None of that runs on Static Hosting. Use DeployHQ's SPA mode for the SPA fallback. For Cloud Function proxying, point the frontend directly at the Cloud Function URL instead of relying on a /api/* rewrite.

Next.js next/image falls back to <img>. Static export disables Next.js Image Optimization. For better performance, pre-optimize at build time with sharp or next-export-optimize-images, or use an image CDN (Cloudflare Images, Imgix, Cloudinary).

What you've shipped

You now have:

A Firebase Studio frontend rebuilding on every push to main
Atomic deploys with no downtime during the transfer
HTTPS over Cloudflare's edge with automatic certificate management
One-click rollback to any previous deployment from the DeployHQ dashboard
Firebase Auth, Firestore, Storage, and Cloud Functions unchanged, doing exactly what they did before
A clean separation between the static UI and Google's backend services

For the broader context of how Static Hosting fits among DeployHQ's other hosting types, see the hosting hub. The Static Hosting pillar guide covers framework auto-detection, SPA mode, and the head-to-head against the most common alternatives. If you're weighing your hosting options more broadly, our DeployHQ Static Hosting vs Vercel comparison is a useful next read for the Next.js side of Firebase Studio projects.

What's next

If your Firebase Studio project outgrows static export — you need real SSR, server-rendered routes you can't move to client-side rendering, or a Node service that doesn't fit the Cloud Functions model — there are two clean upgrade paths inside the same DeployHQ project:

Move SSR rendering to DeployHQ Managed VPS and keep using Firebase services on the backend. The DeployHQ pipeline ships to either target; you swap the server type, not the project.
Split: keep Static Hosting for the public UI, run dynamic parts on Managed VPS or BYO server. The static frontend stays on Cloudflare's edge; the SSR layer runs elsewhere; Firebase services keep doing their thing.

Either path, the build pipeline you set up here continues to work — DeployHQ's build is generic, the target is what swaps.

Built your app with a different AI tool? Bolt, Lovable, and v0 export the same kind of static frontend, each with its own per-tool quirks — our free static hosting for AI-built apps roundup maps where each builder leaves you and how to host the result without lock-in.

For a roundup of how DeployHQ fits alongside the rest of the deployment-tool category, our best software deployment tools in 2026 post is a useful reference. And for context on the broader DeployHQ proposition across all five hosting types it supports, see your universal deployment and hosting platform.

If you're sizing what's included before signing up, the DeployHQ pricing page lays out which plan covers what — the beta-tier Static Hosting site is enough to ship this guide end to end. For the full product reference, see the Static Hosting support library.

Questions or feedback on deploying Firebase Studio apps to DeployHQ Static Hosting? Email support@deployhq.com or follow @deployhq on X for product updates.

How to Deploy a Bolt App to DeployHQ Static Hosting

DeployHQ — Fri, 19 Jun 2026 15:03:34 +0000

DeployHQ Static Hosting serves pre-built static assets from Cloudflare's global edge — exactly what a Bolt.new project produces when its frontend compiles. This guide walks through deploying a Bolt app end to end: export the project to GitHub, sanity-check the build output, provision the site in DeployHQ, configure the build pipeline, and ship the first deploy.

This is the static frontend path. Bolt starter templates often ship with a server/ directory running Express, Hono, or Fastify to handle data and auth — that code needs a Node runtime Static Hosting doesn't provide. If your Bolt app has a server, you have two clean options: run only the static frontend on Static Hosting and point it at your existing API, or use DeployHQ's Managed VPS option to host both the frontend and the Node server in one place. For purely client-side Bolt apps — landing pages, marketing sites, design demos, internal tools, prototypes, anything that talks to third-party APIs from the browser — Static Hosting is the cleanest fit.

What you'll build

By the end of this guide:

A Bolt.new project exported to your own GitHub repository
A DeployHQ project with Static Hosting connected to that repo
A working build pipeline that runs your framework's build command and uploads the output to Cloudflare's edge
The site serving over HTTPS at <subdomain>.deployhq-sites.com (and optionally a custom domain)
Atomic deploys on every push to main, with one-click rollback to any previous version

Expected time: under 15 minutes from a Bolt project you already have generated.

Prerequisites

A Bolt.new project — generated at bolt.new — that you're happy with
A GitHub account Bolt can push to
A DeployHQ account with beta features enabled (enable under Settings > Beta Features )
Node.js installed locally if you want to test the build before pushing (optional but recommended)

If you don't have a DeployHQ account yet, you can start a free trial in the next step — the trial includes one Static Hosting site at no charge while the feature is in beta.

Step 1: Export your Bolt project to GitHub

Bolt runs your project inside a StackBlitz WebContainer in the browser. To deploy it on DeployHQ, the code needs to live in a normal Git repository.

In Bolt:

Open the project you want to deploy
Click the GitHub icon in the top toolbar (or Export depending on your Bolt version)
Authorize Bolt to access your GitHub account if you haven't already
Choose a repository name and visibility, then push

Bolt commits the full project — package.json, framework config files, src/, public/, and any .bolt/ metadata directory — to the main branch of the new repository.

Open the repo in GitHub and confirm package.json is at the root. You'll use it to identify the build command and output directory in the next step.

Step 2: Identify the framework and output directory

Bolt projects are framework-agnostic. The right Static Hosting configuration depends on which framework Bolt scaffolded for you. The build output directory is what matters — Static Hosting uploads the contents of that directory to the edge.

Framework	Default build command	Output directory
Vite + React	`npm run build`	`dist/`
Vite + Vue	`npm run build`	`dist/`
Vite + Svelte	`npm run build`	`dist/`
Astro	`npm run build`	`dist/`
SvelteKit (adapter-static)	`npm run build`	`build/`
Next.js (static export)	`npm run build`	`out/`
Remix (with static adapter)	`npm run build`	`build/client/`

Open package.json and confirm the build script matches what's in the table. Open the framework config (e.g., vite.config.ts, astro.config.mjs, next.config.js) and note any custom output directory if it's been overridden.

If your Bolt project is a Next.js starter, ensure output: 'export' is set in next.config.js — Bolt's default Next.js scaffold assumes a Node runtime. The Next.js deployment guide covers the full static-export configuration.

If your project includes a server/ directory (Express, Hono, Fastify, etc.), that code won't run on Static Hosting — make sure none of your frontend code depends on those endpoints at runtime, or refactor those calls to hit a separate API.

Step 3: Provision a Static Hosting site in DeployHQ

In your DeployHQ project (or create one and connect it to the Bolt repository), click New Server :

Enter a name for the server — internal reference only, doesn't affect the public URL
Select Static Hosting from the protocol picker under Hosting
Choose a subdomain — your site serves at <subdomain>.deployhq-sites.com. Subdomains are unique across all DeployHQ accounts; lowercase letters, numbers, and hyphens only
Set the subdirectory to deploy from to match your framework's output directory from Step 2 (dist/, out/, build/, or build/client/)
Toggle SPA mode based on your framework:
- On for Vite + React SPA, Vite + Vue SPA, Vite + Svelte SPA — these single HTML files use client-side routing and need unknown paths rewritten to index.html
- Off for Astro, SvelteKit static, and Next.js static export — these generate one HTML file per route at build time
Click Create Server

Provisioning takes under a minute. Once the status flips to active, the site exists on Cloudflare's edge — but no code has shipped yet.

Step 4: Configure the build pipeline

DeployHQ runs your build before transferring artifacts to the edge. For a Bolt-exported project, the build pipeline needs two stages: install, then build.

In the project's build settings, add:

npm ci
npm run build

If your package.json declares pnpm or yarn as the package manager (Bolt sometimes does, especially for monorepo-style starters), swap to pnpm install --frozen-lockfile or yarn install --frozen-lockfile.

Environment variables to set in DeployHQ's environment-variable UI:

Public-prefixed env vars your framework inlines into the static bundle (Vite: VITE_*, Next.js: NEXT_PUBLIC_*, Astro: PUBLIC_*)
NODE_ENV=production — usually set automatically but worth confirming for deterministic builds

Anything that isn't prefixed for client exposure stays out of the bundle — that's the framework's standard behavior, not a Static Hosting limitation. If your Bolt project talks to Supabase, Stripe (publishable key), or a third-party API, the URLs and public keys go here. Service-role keys, secret API tokens, and database credentials never belong in a static build.

Ready to take it live? Sign up free for DeployHQ if you don't have an account, and the beta-tier Static Hosting site is enough to ship this guide end to end.

Step 5: First deploy

Push any change to the configured branch (typically main), or trigger a manual deployment from the DeployHQ dashboard. DeployHQ:

Clones the repo at the head of the configured branch
Runs the build pipeline (npm ci && npm run build)
Uploads the contents of your output directory to object storage atomically
Flips Cloudflare's edge routing to serve the new version

The deployment log streams each step in real time. When it completes, visit https://<subdomain>.deployhq-sites.com and confirm the site renders.

If the build fails, the log shows the exact error. Most common failures for Bolt-exported projects:

A starter template that includes a server/ directory the frontend code depends on at build time
Hardcoded paths starting with /home/project/ left over from the WebContainer environment
A missing dependency the package.json declares but Bolt didn't ship a lockfile entry for
Framework-specific config overrides (custom outDir, base, or publicPath) the build pipeline doesn't know about

Fix the issue in the repo, commit, push — DeployHQ runs the next build automatically.

Step 6: Add a custom domain

To serve from your own domain (e.g., app.example.com):

In your DNS provider, add a CNAME record pointing your subdomain to <subdomain>.deployhq-sites.com
Wait for DNS propagation (usually minutes; depends on your TTL)
Cloudflare provisions an HTTPS certificate automatically once the CNAME resolves

Your site now serves from app.example.com over HTTPS via Cloudflare's edge.

Common gotchas

The build pulls in server/ files. Bolt full-stack starter templates expect the server and client to coexist. If your vite.config.ts or framework config includes a path alias pointing into server/, the build will try to bundle Node-only modules and fail. Either remove the alias for a pure frontend deployment, or move the server to DeployHQ Managed VPS.

Hardcoded WebContainer paths. Bolt sometimes leaves /home/project/ paths in generated code, especially in scripts or test fixtures. These break in any environment that isn't a WebContainer. Search the repo for /home/project/ and replace with relative paths or process.cwd().

Build succeeds but the page is blank. Vite + React SPAs often need base: '/' set explicitly in vite.config.ts when deployed at the root. If you're deploying under a subpath, set base: '/subpath/' to match. Check the browser console — a 404 on /assets/index-*.js is the giveaway.

Tailwind classes missing in production. Bolt's Vite scaffold sometimes uses content paths that miss files in nested directories. Verify tailwind.config.ts includes every path your components actually live under — ./src/**/*.{js,ts,jsx,tsx,vue,svelte} covers the standard layout, but Bolt's project structure can vary.

Routes 404 on direct page load (Vite SPA). This is SPA mode not being enabled in DeployHQ. Toggle it on — Static Hosting will rewrite unknown paths to index.html so client-side routing takes over.

Supabase auth callback fails. If your Bolt app uses Supabase and the auth callback URL points to a /auth/callback route handler, it'll 404 because that route handler can't run on Static Hosting. Move the auth-callback logic into client-side code that reads the URL hash, or run the callback handler on a separate backend.

What you've shipped

You now have:

A Bolt project rebuilding on every push to main
Atomic deploys with no downtime during the transfer
HTTPS over Cloudflare's edge with automatic certificate management
One-click rollback to any previous deployment from the DeployHQ dashboard
Predictable, free hosting while Static Hosting is in beta

For the broader context of how Static Hosting fits among DeployHQ's other hosting types, see the hosting hub. The Static Hosting pillar guide covers framework auto-detection, SPA mode, and the head-to-head against the most common alternatives. Since Bolt ships with a one-click Netlify deploy button, the DeployHQ Static Hosting vs Netlify comparison is directly relevant when you're choosing where to host outside the built-in option.

What's next

If your Bolt project outgrows static export — you need to run the server/ directory in production, add real auth, or handle dynamic data without a separate backend — there are two clean upgrade paths inside the same DeployHQ project:

Move to DeployHQ Managed VPS and run the full Node app — both your frontend bundle and your server/ code in one place. The DeployHQ pipeline ships to either target; you swap the server type, not the project.
Split: keep Static Hosting for the UI, run the server/ directory elsewhere. A separate Managed VPS or BYO server hosts the API, and the static frontend stays on Cloudflare's edge.

Either path, the build pipeline you set up here continues to work — DeployHQ's build is generic, the target is what swaps.

Questions or feedback on deploying Bolt projects to DeployHQ Static Hosting? Email support@deployhq.com or follow @deployhq on X for product updates.

How to Deploy a v0 App to DeployHQ Static Hosting

DeployHQ — Thu, 18 Jun 2026 05:45:50 +0000

DeployHQ Static Hosting runs static builds on Cloudflare's global edge — exactly the shape v0 produces when you export a project as a Next.js codebase. This guide walks through deploying a v0 app end to end: export the project to GitHub, provision the site in DeployHQ, configure the build pipeline, and ship the first deploy.

This is the static-export path. If your v0 project uses Next.js server actions, App Router server components, or any backend route handlers, Static Hosting can't run that code — those parts need a Node runtime on DeployHQ's Managed VPS option, a separate serverless layer, or an existing API you call from the client. For purely static UI — marketing pages, landing pages, design demos, internal tools, prototypes — Static Hosting is the cleanest fit.

What you'll build

By the end of this guide:

A v0 project exported to your own GitHub repository
A DeployHQ project with Static Hosting connected to that repo
A working build pipeline that runs next build (with static export) and uploads the output to Cloudflare's edge
The site serving over HTTPS at <subdomain>.deployhq-sites.com (and optionally a custom domain)
Atomic deploys on every push to main, with one-click rollback to any previous version

Expected time: under 15 minutes from a v0 project you already have generated.

Prerequisites

A v0 project — generated at v0.app — that you're happy with
A GitHub account v0 can push to
A DeployHQ account with beta features enabled (enable under Settings > Beta Features )
Node.js installed locally if you want to test the build before pushing (optional but recommended)

If you don't have a DeployHQ account yet, you can start a free trial in the next step — the trial includes one Static Hosting site at no charge while the feature is in beta.

Step 1: Export your v0 project to GitHub

v0 generates Next.js code. To deploy it anywhere outside v0's built-in Vercel target, you need the code in your own repository.

In v0:

Open the project you want to deploy
Click the GitHub icon in the project toolbar (or Export → GitHub depending on your v0 version)
Authorize v0 to access your GitHub account if you haven't already
Choose Create new repository and pick a name, or Push to existing repository if you've already exported once
Confirm the push

v0 commits the full Next.js project — app/, components/, package.json, next.config.js, tailwind.config.ts, and the rest — to the main branch of the repository you selected.

Open the repo in GitHub and confirm next.config.js (or next.config.mjs) is present. You'll edit it in the next step.

Step 2: Configure Next.js for static export

v0's generated next.config.js is set up for Vercel by default, which assumes a Node runtime. Static Hosting needs the export build instead.

Edit next.config.js to add output: 'export' and disable Next.js Image Optimization (it requires a server):

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  images: {
    unoptimized: true,
  },
};

module.exports = nextConfig;

A few things this changes:

next build writes a static export to out/ instead of starting a Node server
Any route using getServerSideProps, server actions, route handlers, or middleware will fail the build — those features need a runtime Static Hosting doesn't provide
next/image falls back to plain <img> rendering — no on-the-fly resizing

Commit and push the change:

git add next.config.js
git commit -m "Configure Next.js for static export"
git push origin main

Optionally, run npm install && npm run build locally first to catch any server-only code paths v0 emitted before DeployHQ runs the same build.

Step 3: Provision a Static Hosting site in DeployHQ

In your DeployHQ project (or create one and connect it to the v0 repository), click New Server :

Enter a name for the server — internal reference only, doesn't affect the public URL
Select Static Hosting from the protocol picker under Hosting
Choose a subdomain — your site serves at <subdomain>.deployhq-sites.com. Subdomains are unique across all DeployHQ accounts; lowercase letters, numbers, and hyphens only
Set the subdirectory to deploy from to out (the default Next.js static export directory)
Leave SPA mode off — Next.js static export generates one HTML file per route, so client-side routing fallbacks aren't needed
Click Create Server

DeployHQ runs framework detection against the connected repository. If a Next.js detected! callout appears, the rule-based detector picked up your next.config.js. Accept the suggested values for a stock v0 export.

Provisioning takes under a minute. Once the status flips to active, the site exists on Cloudflare's edge — but no code has shipped yet.

Step 4: Configure the build pipeline

DeployHQ runs your build before transferring artifacts to the edge. For a v0-exported Next.js project, the build pipeline needs two stages: install, then build.

In the project's build settings, add:

npm ci
npm run build

If v0 emitted a pnpm-lock.yaml or yarn.lock instead of package-lock.json, swap to pnpm install --frozen-lockfile or yarn install --frozen-lockfile accordingly.

Environment variables to set in DeployHQ's environment-variable UI:

NEXT_PUBLIC_* — any public env vars Next.js inlines into the static bundle (API base URLs, public keys, feature flags)
NODE_ENV=production — usually set automatically but worth confirming for deterministic builds

Anything not prefixed with NEXT_PUBLIC_ will not appear in the static bundle — that's Next.js's standard behavior, not a Static Hosting quirk.

If your v0 project hits external APIs (Supabase for auth, a database backend, third-party services), the URLs and public keys go here. Secrets that should never reach the client — service-role keys, private API tokens — stay out of the static build entirely.

Ready to take it live? Sign up free for DeployHQ if you don't have an account, and the beta-tier Static Hosting site is enough to ship this guide end to end.

Step 5: First deploy

Push any change to the configured branch (typically main), or trigger a manual deployment from the DeployHQ dashboard. DeployHQ:

Clones the repo at the head of the configured branch
Runs the build pipeline (npm ci && npm run build)
Uploads the contents of out/ to object storage atomically
Flips Cloudflare's edge routing to serve the new version

The deployment log streams each step in real time. When it completes, visit https://<subdomain>.deployhq-sites.com and confirm the site renders.

If the build fails, the log shows the exact error. Most common failures for v0 exports:

A page or route handler v0 generated that uses a server-only feature (server actions, getServerSideProps)
next/image used without unoptimized: true
A missing dependency v0's package.json declares but didn't ship with a lockfile entry

Fix the issue in the repo, commit, push — DeployHQ runs the next build automatically.

Step 6: Add a custom domain

To serve from your own domain (e.g., app.example.com):

In your DNS provider, add a CNAME record pointing your subdomain to <subdomain>.deployhq-sites.com
Wait for DNS propagation (usually minutes; depends on your TTL)
Cloudflare provisions an HTTPS certificate automatically once the CNAME resolves

Your site now serves from app.example.com over HTTPS via Cloudflare's edge.

Common gotchas

Server actions fail at build. v0 sometimes generates form submissions as server actions. Static export can't run server code at request time, so those builds break. Refactor server actions into client-side fetches that hit a separate API (your existing backend, a Cloudflare Worker, Supabase, etc.).

Route handlers (app/api/*) don't work. Same root cause — they need a Node runtime. Move that logic to a separate backend, or call third-party APIs directly from the client when the keys are public.

Images render but look unoptimized. next/image skips its optimization pipeline under unoptimized: true. For better performance, pre-optimize at build time with sharp or next-export-optimize-images, or use an image CDN (Cloudflare Images, Imgix, Cloudinary).

Build succeeds but routes 404 on the live site. v0 dynamic routes ([slug].tsx) need generateStaticParams to enumerate which paths to render at build time. Without that, the export skips the dynamic routes entirely. Add generateStaticParams returning the list of slugs you want pre-rendered.

Tailwind classes missing in production. v0 occasionally generates class names that Tailwind's content scanner misses. Double-check tailwind.config.ts includes every path your components live under — ./app/ **/*.{js,ts,jsx,tsx,mdx} and ./components/** /*.{js,ts,jsx,tsx,mdx} cover most v0 projects.

Trailing slashes change URLs mid-project. If you add trailingSlash: true to next.config.js after the first deploy, every route URL changes. Set it intentionally at the start, or commit to a redirect plan if you switch.

What you've shipped

You now have:

A v0 project rebuilding on every push to main
Atomic deploys with no downtime during the transfer
HTTPS over Cloudflare's edge with automatic certificate management
One-click rollback to any previous deployment from the DeployHQ dashboard
Predictable, free hosting while Static Hosting is in beta

For the broader context of how Static Hosting fits among DeployHQ's other hosting types, see the hosting hub. The Static Hosting pillar guide covers framework auto-detection, SPA mode, and the head-to-head against the most common alternatives — including our DeployHQ Static Hosting vs Vercel comparison, which is directly relevant for v0 users weighing where to host outside Vercel itself.

For the full Next.js side of the workflow, the Next.js deployment guide goes deeper on configuration choices that apply equally to v0-exported projects.

What's next

If your v0 project outgrows static export — you add real auth, dynamic data, or server actions you can't refactor away — there are two clean upgrade paths inside the same DeployHQ project:

Move to DeployHQ Managed VPS and run a full Next.js Node process. The DeployHQ pipeline you built ships to either target; you swap the server type, not the project.
Split: keep Static Hosting for the UI, run dynamic parts elsewhere. A separate Managed VPS or BYO server handles the API/SSR, and the static frontend stays on Cloudflare's edge.

Either path, the build pipeline you set up here doesn't change.

Questions or feedback on deploying v0 projects to DeployHQ Static Hosting? Email support@deployhq.com or follow @deployhq on X for product updates.

DeployHQ Static Hosting vs Vercel: Features, Pricing, and Which to Choose

DeployHQ — Mon, 15 Jun 2026 13:11:36 +0000

Choosing between DeployHQ Static Hosting and Vercel comes down to one question: are you only shipping a static frontend, or do you have a backend in the picture too? Both run on globally distributed edge networks. Both auto-detect popular frameworks. Both let you push to a Git branch and have a deployed site within a minute. The differences sit one layer up — in pricing predictability, in what you can deploy alongside the static site, and in how locked-in you are to the platform's runtime model.

This guide compares the two head to head: feature parity, where each one wins, current pricing, and the migration path between them.

TL;DR

If you're building a Next.js application that uses server-side rendering, edge middleware, or ISR — choose Vercel. It's the platform built by the Next.js team and nothing else comes close for Next.js-specific features.

If you're shipping a static site or SPA and you already deploy backend code somewhere (a Laravel API on a VPS, a Rails app on a managed server, a WordPress install on shared hosting), DeployHQ Static Hosting gives you one workflow and one bill for the whole stack. The static frontend rides on the same Cloudflare edge that Pages uses, while the same DeployHQ project can ship your backend code to wherever it actually runs.

For a broader view of where each tool sits in the deployment landscape, our roundup of the best software deployment tools in 2026 covers Vercel, Netlify, Cloudflare Pages, and DeployHQ alongside the rest of the category.

At a glance: feature comparison

Capability	DeployHQ Static Hosting	Vercel
Edge network	Cloudflare's global edge	Vercel Edge Network
Framework auto-detection	Yes (rule + AI fallback)	Best-in-class for Next.js
Atomic deploys	Yes	Yes
Custom domains + SSL	Yes (automatic)	Yes (automatic)
SPA mode (client-side routing)	Yes (toggle)	Yes
Server-side rendering	No (static only)	Yes (full SSR + ISR)
Edge functions / middleware	No	Yes
Image optimization	No (use a CDN proxy)	Built-in
Deploy previews per branch	Per-environment in same project	Per pull request
Backend deploys in same pipeline	Yes (VPS, shared, cloud, S3)	No
Pricing model	Fixed monthly per site	Tiered + usage (bandwidth, functions, builds)
Hobby/free tier	Trial includes 1 site	Hobby (free, single seat, 100 GB transfer)
Vendor lock-in	Low (move the build elsewhere any time)	Higher (forms, image opt, edge fns tied to Vercel)

Both products are mature on the basics. The real divergence is in (a) whether SSR matters to your project, and (b) whether you have non-static code that needs deploying too.

When DeployHQ Static Hosting is the right choice

You're deploying a static site or SPA, not a server-rendered Next.js app. Static Hosting is built for compiled output — Hugo sites, Jekyll documentation, Astro marketing pages, statically-exported Next.js builds, SvelteKit pre-renders, plain React/Vue/Angular SPAs. If your build produces a folder of HTML/CSS/JS and assets, DeployHQ Static Hosting will serve it from Cloudflare's edge with the same latency profile Cloudflare Pages offers. See the Next.js deployment guide for the static-export workflow specifically.

You already deploy backend code with DeployHQ — or are planning to. This is the workflow-consolidation case. Most teams shipping a marketing site or web app have something on the backend: a Laravel API on a VPS, a Node service on Hetzner, a WordPress install on shared hosting. If that backend lives in DeployHQ, the static frontend can sit in the same project, share environments and pipelines, and bill on the same monthly invoice. If you're considering DeployHQ Managed VPS Hosting for the backend, the static frontend can ride along on Static Hosting in the same project without any extra setup.

You want predictable pricing that doesn't spike with traffic. Vercel's pricing is tiered with usage-based bandwidth, function invocations, and build minutes — fine on Hobby, surprising on Pro when a post lands on Hacker News. DeployHQ Static Hosting charges a fixed monthly rate per site. A traffic spike is a great problem; it shouldn't also be a billing problem. See the full DeployHQ hosting catalog for an overview of where Static Hosting sits alongside the other managed options.

You don't want vendor lock-in. Vercel's value-adds (image optimization, forms, edge middleware, analytics) are tied to Vercel. If you ever want to move to a different host, you rewrite those pieces. DeployHQ Static Hosting is intentionally thin — it serves your build output and that's most of it. If you outgrow it, your build still produces the same artifact and works anywhere else that serves static files.

When Vercel is the right choice

You're building a Next.js application that uses SSR, ISR, or App Router server components. Vercel is the platform built by the Next.js team. Server-rendered routes, incremental static regeneration, React Server Components, streaming, edge middleware — all first-class. If your Next.js app does anything beyond pure static export, Vercel is hard to beat. (If your Next.js app is only using export, DeployHQ Static Hosting works just as well and costs less; but that's a small subset of Next.js projects.)

You depend on edge functions or middleware for per-request logic. Need to A/B test, rewrite URLs, do geo-based routing, or run authentication at the edge? Vercel's edge runtime is built for that. DeployHQ Static Hosting doesn't run code at request time — you'd put Cloudflare Workers in front of it to add that layer, or move to a runtime that supports middleware natively.

Deploy previews with commenting is your team's workflow. Vercel's per-PR preview links with inline comments are excellent for design and product review. DeployHQ supports per-environment deployments and you can preview each branch, but the per-PR preview-comment UX is a Vercel-specific strength.

You want analytics, image optimization, and forms in one bundled tool. Vercel's product surface is broader. If you'd rather not pick a CDN, an image-optimization service, and a form backend separately, the bundle has real ergonomics value — at the cost of being more tied to Vercel.

Pricing: side by side

Quick comparison at typical small-team scales. Numbers are accurate as of June 2026 — check vendor pricing pages for the current rates before you commit.

Vercel Hobby is free, single developer seat, includes 100 GB fast data transfer, 1M function invocations, 4 hours of active function CPU per month. Good for hobby projects and very small sites.

Vercel Pro is $20 per seat per month plus usage. Includes 1 TB fast data transfer and 1M function invocations included; beyond that, bandwidth, function CPU, and build minutes are usage-billed. Build minutes are priced per machine type ($0.014/min Standard, $0.028/min Enhanced, $0.105/min Turbo). A team site with moderate traffic typically lands in the $40-100/month range — sometimes much higher with bandwidth spikes.

DeployHQ Static Hosting is billed at a fixed monthly rate per site — the rate shown on the Hosted Resources page and on the site setup form in your account's currency, on the same monthly invoice as your DeployHQ plan. Trial accounts can provision one Static Hosting site at no charge. No per-bandwidth, per-build-minute, or per-function-invocation overage to worry about.

If you also need a backend deployed (the consolidation case), the comparison shifts — Vercel Pro plus a separate VPS plus a separate deployment tool quickly exceeds the bundled DeployHQ price. See current DeployHQ pricing for the full plan table.

Moving between them (it's not all-or-nothing)

Both platforms serve the same artifact — a folder of built static files — so migration in either direction is mostly a redirect. The build command and output directory stay the same; only the deployment target changes.

From Vercel to DeployHQ Static Hosting: connect the repository in DeployHQ, point Static Hosting at the same build directory Vercel used (dist, .next/out, _site, etc.), keep the build command identical, and switch DNS once the new site is verified. If you depend on Vercel-specific features (image optimization, edge middleware, forms), plan their replacements first — Vercel image opt → Cloudflare image transformations or a third-party image CDN; Vercel forms → a third-party form service; edge middleware → Cloudflare Workers in front of Static Hosting. For the broader move from various deployment platforms, our migrating to DeployHQ smooth transition guide covers the general pattern.

From DeployHQ Static Hosting to Vercel: even simpler — connect the repo to Vercel, set the same build command and output directory, switch DNS. No DeployHQ-specific features to unwind.

Or: mix them. DeployHQ supports bring-your-own deployment targets alongside its managed hosting. You can keep a Vercel-hosted Next.js app and deploy your Laravel API or your Rails backend with DeployHQ to a VPS in the same project. There's no requirement to consolidate the static side.

What about the Cloudflare edge?

Both DeployHQ Static Hosting and Cloudflare Pages run on Cloudflare's global edge network. Vercel runs on Vercel's own edge network, built on AWS regions plus their own POPs. In practice the latency profile is comparable for most users — within tens of milliseconds depending on geography — but the underlying networks are different. Cloudflare's network is broader (305+ POPs, last published count); Vercel's is narrower but tuned tightly for Next.js workloads.

For pure static content this rarely matters. For edge-function workloads with strict latency SLAs, run your own benchmark from the regions your users actually live in.

FAQ

Can I use a custom domain with DeployHQ Static Hosting?Yes. Add a CNAME record at your DNS provider pointing to your <subdomain>.deployhq-sites.com host. HTTPS certificates are provisioned automatically by Cloudflare. Custom domains are supported on all tiers including trial.

Does DeployHQ Static Hosting support Next.js?Yes, for statically-exported Next.js builds (next export, or App Router pages with output: 'export'). If your app uses SSR, ISR, server components with dynamic rendering, or edge middleware, Static Hosting isn't the right surface — those need a runtime. Use DeployHQ Managed VPS Hosting and run a Node process there, or stay on Vercel.

Can I get deploy previews per pull request? DeployHQ projects support multiple servers (and therefore multiple environments) inside one project, so you can have a staging Static Hosting site that deploys from a staging branch. Per-PR preview links with inline comments are a Vercel-specific feature — DeployHQ doesn't replicate that exact UX.

Is there a free tier on DeployHQ Static Hosting?Trial accounts can provision one Static Hosting site at no charge. Paid plans support additional sites. The trial is what you'd use to evaluate the product before committing.

What if I outgrow Static Hosting? You can move to BYO hosting (deploy to your own S3 bucket, Cloudflare R2, or any S3-compatible storage) in the same DeployHQ project, or move to Managed VPS if your site picked up a backend. Same pipeline, just a different target. If you're outgrowing the static-only model entirely and need a runtime, our shared hosting vs VPS comprehensive guide for junior developers walks through the broader infrastructure trade-offs.

Get started

If you're already on DeployHQ and want to add a static site to an existing project, enable beta features under Settings > Beta Features , then add a new Static Hosting server to your project. The Static Hosting on DeployHQ pillar guide walks through the provisioning flow end-to-end.

If you're new, start a free trial and the trial includes one Static Hosting site so you can compare the workflow against your current Vercel setup before deciding. For the broader picture of where Static Hosting fits among the five hosting types DeployHQ supports, see your universal deployment and hosting platform.

Both DeployHQ Static Hosting and Vercel are good at what they're built for. Pick based on what's actually around your static site — if it's all static or you're consolidating workflows for a backend you also ship, DeployHQ Static Hosting fits. If you're deep in Next.js SSR territory, stay on Vercel and don't fix what isn't broken.

For more detail on the DeployHQ Static Hosting product itself, the Static Hosting support library has the full provisioning, framework-detection, and lifecycle documentation. And the build pipeline feature page covers what runs on the DeployHQ side before the upload step fires.

Questions or feedback on Static Hosting vs Vercel? Email support@deployhq.com or follow @deployhq on X for product updates.

Tie every Sentry error to the DeployHQ deploy that caused it

DeployHQ — Tue, 02 Jun 2026 06:41:16 +0000

The 2 AM problem: errors without deploy context

It's 2 AM. Sentry pages you — your production error rate just spiked 4x. You roll out of bed, open the Sentry dashboard, and stare at a wall of new issues. The team shipped five deploys today.

Which one broke it?

You open DeployHQ in another tab. You squint at timestamps. You cross-reference commit SHAs against the stack traces. Maybe you guess. Maybe you roll back the wrong release. The next morning, the team has to reconstruct what actually changed — and the on-call has a coffee, not a story.

This isn't a Sentry problem or a DeployHQ problem. Each tool is excellent in isolation. The gap is the missing join: which deploy introduced this error?

DeployHQ closes that gap. Every shipped deploy gets posted to Sentry as a release with its commit SHA, environment, and timestamp. From then on, Sentry doesn't just tell you something broke — it tells you what shipped, when, and by whom. Issues get attributed to the release that was live. Regressions surface against the release that caused them. One-click rollback in DeployHQ becomes the obvious next move instead of a guess.

The cost of not wiring this up compounds. Longer mean time to recovery. Blame games. And the cultural drift where deploys quietly become scary events that get pushed to Tuesday afternoon to be safe. If you've ever stalled a release on a Friday because the team was too tired to handle a regression, you've felt this gap. For the broader principle, see our take on what you should be monitoring on every deployment.

The deploy → release link in plain terms

Two views of the same event, one shared key.

In Sentry, a release is a version of your code deployed to an environment, tagged with a commit SHA. When issues come in, Sentry attributes each one to the release that was live when it occurred. New issues that first appear right after a release are the ones you care about most — they're regressions, not background noise.

In DeployHQ, a deploy is the act of building that commit and pushing it to a specific environment. Each deploy has a SHA, a target environment (production, staging), and a timestamp.

The join key is the commit SHA. Not timestamps — clock drift between systems will burn you. Not deploy IDs — those are internal to each tool. Just the SHA. If both systems know the SHA of the code that's running, they can answer which deploy introduced this error? without anyone guessing.

This matters more once you're shipping continuously. With a release a week, you can hold the last five SHAs in your head. With five a day, you can't — and you shouldn't have to. If that part of the picture is fuzzy, our primer on continuous deployment workflows walks through the moving parts.

Setting up the Sentry integration in DeployHQ

DeployHQ ships a native Sentry integration — no shell scripts, no sentry-cli calls, no cron jobs.

Open your DeployHQ project, click Integrations in the left sidebar, then New Integration. Select Sentry from the service picker and fill in the configuration.

You'll need four things:

Organization Slug : the URL-safe identifier of your Sentry organization. Find it in the URL when you're signed into Sentry (sentry.io/organizations/<your-slug>/) or under Settings → General.
Project Name : the project inside that organization where releases should be posted.
Environment : must exactly match the environment string your Sentry SDK reports — typically production or staging. Mismatches are the most common reason releases don't line up with issues, so double-check the spelling.
Auth Token : a Sentry auth token with the project:releases scope. Create it in Sentry under Settings → Account → API → Auth Tokens (or, for organization-level tokens, Settings → Auth Tokens ). Per Sentry's current Releases documentation, project:releases is the scope required to create releases for the project.

If you're running self-hosted Sentry, also fill in the Installation URL — the base URL of your internal Sentry instance. Everything else is identical.

Pick the events that should trigger the integration (a successful deployment is the common choice), select the servers you want it to fire for, and click Create Integration.

The full setup steps live in our Sentry integration documentation if you need a reference while clicking through.

Tracking releases after the integration is live

Once configured, run a deployment to any server in your project. DeployHQ posts a new release event to your Sentry project, where it'll appear in the Releases area for the matching environment.

From that point forward, issues reported to the project gain release context: each event is attributed to the release that was live when it happened.

The Sentry dashboard gains a few things that didn't exist before:

Filter issues by release so you can see only what regressed since the last shipment
Per-release timelines showing issue counts against release events, so spikes line up visually with deploys
Regression detection — Sentry surfaces issues that reappear in a new release after being marked resolved
Crash-free release tracking for applications using Sentry's session tracking

If a release goes wrong, you have everything you need to act: the offending commit SHA, the release that introduced it, and the engineer who shipped it. From there it's a one-click rollback in DeployHQ — no SSH session, no rerun-from-master gymnastics, no zero-downtime deployment reversed by hand.

Start tracking releases against Sentry issues today — sign up for DeployHQ and wire up the Sentry integration in under five minutes.

Which servers should trigger notifications?

By default, DeployHQ fires the integration for every server in the project. Keep this on if your Sentry project tracks a single environment — usually production.

Two patterns worth knowing:

One Sentry project per environment (the cleanest setup). Add two DeployHQ integrations — one mapped to your production servers with environment production, another mapped to your staging servers with staging. Each Sentry project then sees only its own releases, and you can alert independently.
Single Sentry project, multiple environments. Use one integration but set up server-group filtering so only deploys to specific server groups fire the notifier. Then rely on Sentry's environment filter to separate releases inside the Releases view.

A common gotcha: if your Sentry SDK reports environment as production but the DeployHQ integration sends prod (or live, or prd), Sentry treats those as separate environments and silently drops the release attribution. Pick one canonical spelling and use it everywhere — the SDK config, the DeployHQ integration, your environment variables.

What this unlocks beyond MTTR

Faster incident response is the headline win, but tying releases to issues changes day-to-day work in subtler ways too.

Change failure rate becomes measurable. One of the four DORA metrics — change failure rate — is the percentage of deploys causing degraded service or requiring remediation. Without release tagging, you're estimating. With Sentry releases + DeployHQ deploys, you have a clean ratio.
Deploys stop being scary. Teams that can pinpoint the failing release in seconds ship more often, not less. Friday afternoons stop being off-limits.
Post-incident reviews get shorter. Instead of debating did this start before or after the 14:32 deploy?, the timeline is the answer.
Per-author attribution falls out of the SHA join. Sentry knows the release; DeployHQ knows who triggered it. Not for blame — for routing the regression to the engineer with full context.
Crash-free release health. Once releases are reported, Sentry's release-health features (adoption tracking, crash-free percentages, regression surfacing) light up for applications using its session tracking.

If your stack uses a different error tracker, the same pattern applies — we shipped Bugsnag deploy tracking with DeployHQ, Honeybadger deploy tracking with DeployHQ, and Rollbar deploy tracking with DeployHQ using identical mechanics. The point isn't which error tracker you use — it's that errors without deploy context cost more than they should.

For teams that want every deploy log analyzed automatically (not just notified), DeployHQ also offers AI-powered deployment log analysis — so the next-step decision after a Sentry spike isn't scroll through 3,000 lines of build output but read the summary.

Wrapping up

You'll now be able to report every deployment to Sentry and tie issues back to the release that caused them — without writing a single line of integration code. Two minutes of setup; permanent context on every error.

The Sentry integration has been part of DeployHQ since 2019, when we shipped it alongside our other error-tracking integrations, and has been quietly working in customer projects ever since. Per Sentry's current Releases documentation, the dashboard features that benefit from this — filtering by release, regression detection, per-release timelines, crash-free tracking — only light up once releases are being reported, which is exactly what this integration does for you.

If you have any questions about the Sentry integration or any other aspect of DeployHQ, please don't hesitate to email support@deployhq.com or reach out on @deployhq.

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

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

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

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

What you'll build

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

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

Why self-host n8n at all?

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

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

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

Prerequisites

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

Step 1: Provision the VPS

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

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

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

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

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

Confirm passwordless login works:

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

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

Step 2: The n8n Docker Compose stack

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

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

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

volumes:
  postgres_data:
  n8n_data:

Four things matter here:

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

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

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

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

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

On the VPS, install Nginx and Certbot:

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

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

server {
    server_name workflows.yourdomain.com;

    client_max_body_size 50M;

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

    listen 80;
}

Enable it and run Certbot:

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

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

Step 4: First run

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

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

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

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

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

Step 5: Wire up Git-based deploys with DeployHQ

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

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

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

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

Step 6: Workflows as code

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

The flow:

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

A few practical notes:

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

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

Step 7: Upgrade n8n safely

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

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

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

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

Two upgrade hygiene tips:

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

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

Step 8: Backups

Two things to back up:

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

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

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

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

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

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

Where to go from here

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

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

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

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

DeployHQ CLI: Deploy From Your Terminal (or Let Your AI Agent Do It)

DeployHQ — Mon, 11 May 2026 13:56:25 +0000

If you have ever wished you could deploy without leaving your terminal — no browser tab, no dashboard click, no context switch — that is exactly what the new DeployHQ CLI is built for. It is a single Go binary, called dhq, that wraps the entire DeployHQ API. You install it once and you can trigger deployments, watch them in real time, tail logs, and roll back from the command line. And because the output is machine-readable by default, your AI coding assistant can do the same thing on your behalf.

This guide walks through installing the CLI, authenticating, running your first deployment, watching it live, tailing logs, and rolling back. Then we cover the part most teams care about in 2026: wiring dhq into Claude Code, Cursor, Codex, and Windsurf so an AI coding agent can drive your deployments end to end.

Why a Terminal-First Deployment Tool Matters

Deploy steps are the easiest place for an engineering workflow to break flow. You finish a fix, you push, the test suite passes — and then you alt-tab to a browser to click a button. With a CLI on your $PATH, that step collapses into a single command. With the same CLI exposed to your AI assistant, the deploy step disappears from your workflow entirely: the assistant proposes it, you approve, it ships.

That second use case — agent-driven deployment — is why DeployHQ rebuilt the CLI from scratch. The previous Ruby gem (gem install deployhq) is now deprecated. The new tool, dhq, follows a strict output contract designed for both humans and agents:

stdout is always data — a clean table for humans, JSON when piped or when --json is set
stderr is always human messages — progress, warnings, errors
No interactive prompts when all required flags are provided

If you have read our take on why CLIs are the cleanest integration surface for AI coding agents, this is what that argument looks like in practice for deployments.

Installing the DeployHQ CLI

dhq ships as a single binary for macOS, Linux, and Windows (amd64 and arm64). Pick the install method that matches your environment:

# macOS (Homebrew)
brew install deployhq/tap/dhq

# Linux or macOS (universal install script)
curl -fsSL https://deployhq.com/install/cli | sh

# Windows (Scoop)
scoop bucket add deployhq https://github.com/deployhq/scoop-bucket
scoop install dhq

# From source (Go)
go install github.com/deployhq/deployhq-cli/cmd/dhq@latest

After install, confirm the binary is on your $PATH:

dhq --version

Both dhq --version and dhq version work — use whichever fits your scripts.

Authenticating

dhq supports two authentication paths: an interactive login that stores credentials in your OS keyring (for everyday human use), and environment variables (for CI runners and AI agents).

For the interactive flow:

dhq auth login

You will be prompted for your account domain (e.g. my-account.deployhq.com), your email, and an API key from Settings → Security. You can create or revoke API keys from the DeployHQ API settings page.

For non-interactive environments — CI runners, Docker images, AI agent sandboxes — set three environment variables instead:

export DEPLOYHQ_ACCOUNT="my-account"
export DEPLOYHQ_EMAIL="you@example.com"
export DEPLOYHQ_API_KEY="..."

This is the same pattern we recommend when pointing AI agents at CI/CD pipelines: credentials live in the runner's secret store, never in prompts or repo files.

Your First Deployment

The five commands you will reach for most often:

Command	What it does
`dhq projects list`	List projects on your account
`dhq servers list -p <project>`	List servers and groups for a project
`dhq deploy -p <project> -s <server>`	Trigger a deployment with live progress
`dhq deployments watch -p <project>`	Stream live progress for a deployment already running
`dhq deployments logs <id> -p <project>`	Fetch logs for a specific deployment
`dhq rollback <id> -p <project>`	Revert a previous deployment

A typical session looks like this. Discover what you have access to:

$ dhq projects list
NAME PERMALINK REPO
api-service api-service github.com/acme/api
marketing-site marketing-site github.com/acme/marketing

$ dhq servers list -p api-service
NAME IDENTIFIER TYPE BRANCH PATH
production prod-srv-01 SSH main /var/www/api
staging stage-srv-01 SSH main /var/www/api-staging

Then deploy. With --wait, you get a live TUI progress bar that updates as the deployment runs through its phases (fetch repo → build → upload → run SSH commands):

$ dhq deploy -p api-service -s staging --wait

When the deployment is done, the CLI exits with status 0 on success and non-zero on failure — exactly what your shell scripts and CI runners need.

Watching, Logs, and Rollback

Three operations turn the CLI from a fire and forget trigger into a control plane you can run from one terminal window.

Watch a deployment live. If a deploy is already in flight, attach to it from anywhere:

dhq deployments watch -p api-service

The watch view streams the same TUI you would see from --wait, but for a deployment that started elsewhere — useful when a teammate or a CI job kicked it off and you want to monitor without refreshing the dashboard.

Tail logs after the fact. When something fails, you want the full log without scrolling through the web UI:

dhq deployments logs DEP-12345 -p api-service

For agent-friendly output, add --json and pipe into jq:

dhq deployments logs DEP-12345 -p api-service --json | jq '.data.entries[] | select(.level=="error")'

Roll back a bad deploy. If a release goes sideways, revert to the previous successful deployment:

dhq rollback DEP-12345 -p api-service --wait

Rollback uses the same diff engine as a forward deploy, so the only files that move are the ones that changed. This is the same one-click rollback primitive exposed in the web UI, just from your terminal.

Output Contract: Why It Matters for AI Agents

Most CLIs were not designed to be called by AI coding agents. They mix progress messages with data on stdout, throw interactive prompts when you forget a flag, and return unstructured text that the agent has to guess how to parse.

dhq was built around three rules that fix that:

stdout is data, stderr is text — a piped command always returns parseable output; status messages never pollute it
JSON on demand, JSON when piped — dhq deploy ... --json returns machine-readable output, and the same auto-switches when stdout is a pipe
Breadcrumbs in every JSON response — the CLI tells the agent what to do next

A typical JSON response includes a breadcrumbs array that explicitly lists the next reasonable command:

{
  "ok": true,
  "data": { "deployment_id": "DEP-12345", "status": "completed" },
  "summary": "Deployment DEP-12345 to staging completed in 47s",
  "breadcrumbs": [
    {"action": "logs", "cmd": "dhq deployments logs DEP-12345 -p api-service"},
    {"action": "rollback", "cmd": "dhq rollback DEP-12345 -p api-service"}
  ]
}

The agent does not have to memorise the command surface. It runs one command, reads the breadcrumbs, and knows what to chain next. On failure the envelope flips — {ok: false, error, recovery} — so the agent gets the same structured handle on what went wrong and what to try next.

Wiring `dhq` Into Your AI Coding Assistant

This is where the real workflow change happens. With dhq on $PATH and the right rules file in your repo, your AI editor can deploy your code without you ever opening a browser. A full companion guide on driving DeployHQ from Cursor, Claude Code, and Windsurf is in the works (sister post coming Week 7) — what follows is the short version.

The pattern is the same across all four editors below: the capability lives in the editor's permissions config; the judgement lives in a behavioural rules file. Read-only commands (projects list, servers list, deployments logs, deployments watch) are safe by default. Destructive ones (deploy, rollback) should require an explicit human approval gate.

Claude Code

Claude Code governs shell access through .claude/settings.json. Allow the read-only dhq commands; require approval for the destructive ones:

{
  "permissions": {
    "allow": [
      "Bash(dhq projects:*)",
      "Bash(dhq servers list:*)",
      "Bash(dhq deployments logs:*)",
      "Bash(dhq deployments watch:*)"
    ],
    "ask": [
      "Bash(dhq deploy:*)",
      "Bash(dhq rollback:*)"
    ]
  }
}

Then drop a CLAUDE.md block at the project root telling Claude when to reach for the CLI. Behavioural rules belong in CLAUDE.md; we cover the full pattern in our guide to CLAUDE.md, AGENTS.md and Copilot Instructions:

## Deployment

This project uses DeployHQ. Use the `dhq` CLI for all deploys.

- After the test suite passes on a branch, propose `dhq deploy -p <project> -s staging --wait` and wait for my approval.
- Never run `dhq deploy ... -s production` without an explicit instruction containing the word "production".
- For a failing deploy, fetch logs with `dhq deployments logs <id>` before suggesting a fix.
- For a regression in production, propose `dhq rollback <id>` first, then debug.

Cursor

Cursor's Composer agent shells out the same way. Drop the rules in .cursor/rules/deployhq.mdc — that is the path current Cursor versions auto-load, with .mdc frontmatter:

We deploy with DeployHQ via the `dhq` CLI.

When asked to deploy:
1. Confirm the target environment in your message before running the command.
2. Use `dhq deploy -p <project> -s staging --wait` for staging.
3. For production, ask me to confirm in the chat before issuing the command.
4. After triggering, check `dhq deployments watch` until completion or failure.
5. On failure, run `dhq deployments logs <id>` and summarise the error before suggesting a fix.

Codex CLI / Windsurf

OpenAI's Codex CLI and Windsurf's Cascade agent both run shell commands natively. Once dhq is on $PATH they can call it without extra config — the work is in giving them the right behavioural rules so they do not deploy the moment they feel confident. We compared the three terminal agents in detail in Claude Code vs Codex CLI vs Gemini CLI, and the deployment pattern that emerged is the same: read commands open, write commands gated by an explicit instruction.

For an even shorter setup, dhq setup writes the right files for each editor in the right place — no manual config copying:

dhq setup claude # writes ~/.claude/skills/deployhq/SKILL.md
dhq setup cursor # writes .cursor/rules/deployhq.mdc in the current repo
dhq setup codex # writes AGENTS.md in the current repo
dhq setup windsurf # writes global_rules.md

Each variant installs a behavioural rules file the editor actually auto-loads, plus a SKILL.md decision tree and reference docs that teach the agent when each dhq command is appropriate. More on the design choices behind that in our piece on the developer CLIs that AI coding agents actually use well.

Using `dhq` in CI/CD

The same output contract that makes the CLI work for AI agents makes it trivial to drop into CI. A minimal GitHub Actions step:

env:
  DEPLOYHQ_ACCOUNT: ${{ secrets.DEPLOYHQ_ACCOUNT }}
  DEPLOYHQ_EMAIL: ${{ secrets.DEPLOYHQ_EMAIL }}
  DEPLOYHQ_API_KEY: ${{ secrets.DEPLOYHQ_API_KEY }}

steps:
  - name: Install dhq
    run: curl -fsSL https://deployhq.com/install/cli | sh

  - name: Deploy to staging
    run: dhq deploy -p api-service -s staging --wait --json

Auth via env vars, JSON output for machine parsing, exit code drives the build status. If the deploy fails, the CI job fails — no extra plumbing required. For more on running AI agents inside the same kind of pipeline, see our piece on agentic workflows in CI/CD.

Migrating From the Old Ruby Gem

If you have the old gem install deployhq tool installed, the migration is straightforward:

Install dhq using one of the methods above.
Run dhq auth login (or set the DEPLOYHQ_* environment variables) — your existing API keys still work.
Update any scripts that called deployhq deploy to dhq deploy -p <project> -s <server>.
Once everything is working, gem uninstall deployhq to remove the old tool.

The old Deployfile JSON format is no longer required — dhq reads project context from flags, environment variables, or your interactive auth state. This is a breaking change, but a small one: most users had a single Deployfile per repo, and the new flags are easier to drop into Makefiles, scripts, and CI configs.

Where to Go Next

The CLI is one piece of a larger story. DeployHQ is increasingly designed for both humans and agents — the DeployHQ agents page walks through how the platform thinks about tool design for AI editors, and where we are heading next.

If you do not have a DeployHQ account yet, start a free trial — install dhq, point it at your first project, and you can run an automated deployment from your terminal inside ten minutes.

Questions, edge cases, or feedback on the CLI? We would love to hear from you — drop us a line at support@deployhq.com or find us on @deployhq.

New DeployHQ integrations: Linear, Google Chat, Telegram, and signed webhooks

DeployHQ — Fri, 08 May 2026 13:35:35 +0000

We've spent the last few weeks closing the gap between the deploy finished and the right people know it finished. That gap is where production incidents hide: someone shipped a hotfix at 4pm, the chat channel was muted, the PR reviewer assumed it was still in staging, and the customer-facing status page never updated.

Five new integrations are now live, each filling a different version of that gap. One pushes status back into the place where engineers already review code. Three send alerts into the chat tools your team actually watches. The last one is a signed webhook for everything else — status pages, dashboards, CRMs, audit logs.

Deploy status, posted back to GitHub, GitLab, and Bitbucket

The new deployment notifications integration closes the most common visibility gap of all: a pull request shows the diff, the conversation, and the test results — but says nothing about whether the merge actually shipped, where it shipped to, or when. We covered why that gap matters in a comparison of how developers track pull requests, and the same logic applies after merge: reviewers shouldn't have to guess what happened to their code.

Once enabled, every DeployHQ deploy reports back to the originating Git provider. On GitHub, deploys appear under the Deployments tab and as commit statuses on PRs. On GitLab, they show up in the Environments view and on the merge request widget. On Bitbucket, they populate the native Deployments panel. You can map projects to environments — production, staging, QA, preview — so reviewers can see which commit landed where without leaving the code review.

There's no separate auth dance: the integration reuses the repository connection you already configured, and the audit trail of every deploy lives where the rest of your code history lives.

A Linear Release for every deploy, automatically

Release tracking is one of those tasks that sits between engineering and product, gets assigned to nobody, and quietly atrophies. The Linear integration takes it off the backlog: every time DeployHQ finishes a deploy, a Linear Release lands in your chosen pipeline — already linked to the issues that shipped, based on the issue IDs in the commit messages between this deploy and the last one.

The integration takes a single Linear API key and lets you route different environments to different release pipelines. Production deploys can populate your customer-visible release pipeline; staging deploys can populate an internal one. The integration only creates Releases — it doesn't move issues between states, so it composes cleanly with whatever workflow automation you already have. If you've thought about the difference between continuous delivery and continuous deployment, this is the seam where the two meet — automatic Releases let you keep continuous-delivery discipline without manual bookkeeping.

Card-formatted alerts in Google Chat spaces

For teams running on Google Workspace, the Google Chat integration drops deploy notifications straight into your existing spaces as native cards. Project name, branch, environment, deployer, and status are all visible at a glance — no plain-text wall.

Different projects can route to different spaces, or one project can broadcast to several. Useful pattern: send infra deploys to a quiet deploys-firehose space and customer-facing app deploys to your main engineering space, so the noise lives somewhere you can mute and the signal stays where people are paying attention. This is the same pattern we recommended when we enhanced our Slack notifications, now extended to Google Workspace teams.

Telegram alerts for the on-call rotation

Slack and Discord aren't the right fit for everyone. International teams, contractor pools, and on-call rotations often live in Telegram, where notifications hit personal devices reliably without a paid seat or a workspace invite. (For teams already on Discord or Microsoft Teams, we have a separate guide for routing deployment notifications there.)

The new integration uses the Telegram Bot API to push deploy alerts to any chat, group, or channel. Setup is three steps: create a bot through @botfather, add it to your destination, and paste the token plus chat ID into DeployHQ. There's no Telegram-side server to host — the bot infrastructure is Telegram's. A common deployment pattern: a private channel for production alerts that on-call engineers subscribe to, plus a group chat for the broader team.

Signed HTTP webhooks for everything else

Pre-built integrations cover the common destinations, but there's always a long tail: a customer-facing status page, an internal compliance log, a CRM that needs to know when a customer's tenant deployed, a custom dashboard the platform team built last quarter. The HTTP webhook integration handles those.

Every deploy event — start, success, failure — fires a signed POST to whatever URL you configure. Each request includes an X-DeployHQ-Signature header containing an HMAC-SHA256 of the raw body, keyed by your shared secret, so the receiving service can verify the request actually came from DeployHQ and wasn't replayed or forged. That matters as soon as the receiving endpoint is publicly reachable, which most webhook endpoints are.

If you'd rather poll than receive, the same data is available through the DeployHQ API for scripted deployment workflows. Common destinations we've seen people wire up: Statuspage and Atlassian Status, Datadog events, internal Postgres audit tables, ServiceNow tickets, custom Slack apps with richer formatting than the stock connector, and customer-success tools that surface deploy timing during support conversations.

Where this fits

Each of these reuses your existing DeployHQ project configuration — the same Git deployment automation you already have running picks up the new notification target on its next run. Multiple integrations can run in parallel: a single deploy can post a commit status to GitHub, create a Linear Release, drop a card into Google Chat, ping a Telegram channel, and fire a webhook to your status page.

For a wider tour of what plugs into DeployHQ — error trackers, monitoring tools, project management — the DeployHQ integrations roundup covers the broader picture, and the integrations index lists every pre-built connector. If your destination isn't there, the signed webhook covers it.

If you're not deploying with DeployHQ yet, start a free trial and wire up your first integration in the dashboard — most teams have deploy notifications flowing inside ten minutes.

Got questions or a destination you'd like us to integrate with natively? Reach us at support@deployhq.com or @deployhq on X.