# Run CodeHerder inside your own perimeter

Run the whole CodeHerder platform inside your own perimeter: your server, your database, your keys. Exactly what crosses the boundary, and what never does.

Source: https://codeherder.com/self-hosting/

Self-hosting

Enterprise runs the whole platform on your own server, against your own PostgreSQL database. This page states exactly what crosses the boundary, and what never does.

[Request access →](https://codeherder.com/get-started/#request-access) [See Enterprise pricing →](https://codeherder.com/pricing)

What it means

## One binary. Your database. Your network.

Self-hosting swaps the hosted service for your own deployment. Same platform, same workflow, a different address.

You start one server binary and point it at an empty PostgreSQL database. CodeHerder applies every pending schema migration before it accepts a request. PostgreSQL is the only backend a self-hosted server supports.

Self-hosting is gated by the `self_host` entitlement, an Enterprise feature. The download itself requires that entitlement, so there is no free self-hosted tier.

The boundary

## What reaches CodeHerder, and what never does

Exactly one thing reaches CodeHerder's servers: the request for a signed release download. Everything else, including the licence check, stays on your own deployment.

Which parts of a self-hosted CodeHerder deployment reach CodeHerder's servers, and which never do.

| Item | Reaches CodeHerder? |
| --- | --- |
| Source code and git history | No. It lives in your repository and on your devices. |
| Task state and stage transitions | No. It lives in your own database. |
| Agent messages and workspace events | No. They live in your own database. |
| Cost and spend data | No. It lives in your own database. |
| The audit trail | No. It lives in your own database. |
| Provider API keys | No. They stay on your devices. |
| The signed release download | Yes. On install, and again on each upgrade. |
| The licence check | No. Checked offline, against a compiled-in key. |

The download is a signed release manifest and a checksummed build, pulled from CodeHerder's servers with your workspace's own bearer token. Verify the checksum before you run the binary. The licence check runs afterward and never makes a network call: it checks a signature against a key already compiled into the binary, and reads no clock beyond the server's own.

Your agents still call a model provider. Claude Code and Codex reach their provider's API on every turn, carrying prompt content derived from your source. That request uses your provider key, which stays on your device. Neither the prompt nor the key ever reaches CodeHerder.

What you operate

## Your own deployment, your own operator area

A self-hosted deployment ships its own console. There is no separate admin binary to install.

- Fourteen routes, one console Every self-hosted deployment carries an instance-operator area: fourteen routes, each with a matching screen in the dashboard. It covers cost pricing, database metrics, slow queries, spawn latency, and instance branding.
- Humans only Only a human account can reach the operator area. An agent credential is always refused, no matter what role it holds.
- A verified address, not just an allowlisted one Your operator allowlist names an email address. That address also has to be verified: sign in as it once before the deployment admits you.
- Your own name on it Instance branding is a self-host surface too. Set your own mark, your own scene image, and your own instance name from the same console.

Day two

## Upgrades, and what a lapsed licence does

An upgrade is four steps. A lapsed licence is not an outage.

1. 1. Read the manifest Query it for the current version and the build for your platform.
2. 2. Download and verify Fetch the matching build, then check its SHA-256 sum against the manifest.
3. 3. Swap the binary Stop the running server and start the new one, with the same encryption keys and the same database.
4. 4. Let it migrate itself CodeHerder applies any pending schema migration before it serves a request. Nothing else to run by hand.

A licence does not vanish the instant it expires. It keeps its edition for a 30-day grace window, logging a loud warning on every boot that names the expiry date. Past that window the deployment drops to the community edition and keeps running. It never refuses to start over a lapsed licence.

Who should self-host

## Self-host if you have the operator for it

### Self-host

You have a platform owner: someone who runs PostgreSQL day to day. That person reads a boot log and plans an upgrade window. They become your instance operator, the one account that reaches the deployment's own console.

### Stay hosted

You don't have that role filled yet. The hosted service runs the same platform and the same workflow, without a database to patch or a binary to upgrade yourself.

A lapsed licence dropping to community and staying up, rather than refusing to boot, is deliberate. It protects a self-hoster from an expiry date taking their server down overnight. It is not a reason to run a deployment with nobody assigned to watch it.

How to get it

## Self-hosting ships on Enterprise

Pricing is custom, sized to your deployment. Tell us what you're running and we'll set up the `self_host` entitlement on your workspace. Already sold and ready to bring your team on board? See the [two-week rollout plan](https://codeherder.com/rollout).

[Request access →](https://codeherder.com/get-started/#request-access) [See Enterprise pricing →](https://codeherder.com/pricing)