Where You Host Paperclip Decides Three Things

Ask where to host Paperclip and you get a list of providers. It's the wrong list. Wherever you run it, you are deciding three things: who else can read your data, what can reach your instance from outside, and whose problem it is when the database disappears. A provider name answers none of them.

Start with the instance you already have. GET /api/health reports which mode and exposure your server believes it is running under. Set that against what you meant to configure. If the two differ, you have found the real question before spending a minute on the provider one.

One distinction first, because it decides which piece you need. Paperclip is the organization: the platform holding your goals, your agents' mandates, and the governance rules between them. Which adapter an individual agent runs on is a separate question, covered in Which Paperclip adapter for which agents. This piece is about where the platform itself lives, before any agent has anywhere to run.

What self-hosting Paperclip requires

Paperclip is a Node.js server with a React front end, open source under MIT.

The documented server requirements are Node.js 24.11 or newer for the managed installer, and Node.js 24.11 with pnpm 9.15 or newer for a source checkout. The server needs a database: an embedded instance is created automatically for local and development use, and the project's own guidance for production is to point Paperclip at a Postgres instance you run, then deploy the server however you like. Packaged Docker images and Compose files cover both paths, including a fuller stack pairing the server with a separate Postgres 17 container. (README.md and README.md FAQ; doc/DOCKER.md. Version numbers read at v2026.916.0 — the shape is stable, the numbers are not.)

None of that is a hosting decision. It is the fixed list any hosting decision has to satisfy: somewhere to run a Node.js process, somewhere to persist a Postgres database, and a network path in for whoever is meant to reach it. What varies is who provides those three things, and how much of each you administer yourself.

Three categories, at the level that holds up

Paperclip publishes no ranked list of places to run it, and we will not invent one we cannot check. What we can state is what each category settles and what it leaves to you.

Hardware you own. A machine on your premises, or one you racked yourself. You decide the network it sits on, who has physical access, when it is patched, and where the backups live. You inherit nothing from anyone else's defaults, which is also why nothing is handled for you.

A server you rent and administer. A virtual or dedicated machine leased from a provider, on which you install and run Paperclip yourself. You inherit the provider's data-centre security and physical access controls. The operating system, network exposure, database and backup schedule remain yours to configure. This is the closest match to Paperclip's own documented manual and Docker paths.

A platform administered for you. Someone else runs the server process, the database and the network layer, and you work against a configured instance. Less to administer, and less to decide: that platform's defaults for exposure and backups become your defaults, whatever they turn out to be.

The wider self-hosted-versus-managed argument, including where each kind of self-hostable tool sits relative to Paperclip, is in Paperclip Alternatives and Competitors. Read it alongside this section rather than after it.

The three properties the choice decides

Whichever category you pick, three properties get an answer.

Who holds the data. Whoever runs the database process can read what is in it.

What is reachable from the public internet. Whatever the server binds to, and however the network in front of it is configured, decides what an outside caller can reach, before any application login is checked.

Who owns the backups. Whoever controls the backup schedule and its storage is the one who can restore from it, and the one who finds out first when a backup silently stops running.

That is our read of what the hosting decision turns on, not a reported finding. It is the frame we think these categories reduce to, and a reader who can point to an arrangement where one of the three is settled somewhere other than the hosting choice would be pointing at a real gap in it. Hardware you own, a rented server, a platform administered for you: the same three get an answer either way. Only the person answering changes.

What the health endpoint tells you

The first two properties are checkable rather than asserted. Paperclip's server reports part of its own configuration on its health route, so you can read it instead of trusting your memory of what you set up.

At v2026.916.0, GET /api/health on a healthy, database-connected deployment returns status, deploymentMode, deploymentExposure, localAiLoginSupported, commit, bootstrapStatus and bootstrapInviteActive. A deployment with no database configured, or one whose database probe fails, returns a narrower set. Where backup-health inspection is configured, the body also carries databaseBackup, with enabled, status and warnings.

(Locators: server/src/routes/health.ts, mounted under /health on the API router in server/src/app.ts. First read at v2026.831.1 on 2026-09-10, re-read against v2026.916.0 on 2026-09-20.)

That is the field set at this tag, not the complete set the route will ever return. localAiLoginSupported was absent at the tag we first checked and joined the body in this release, which is exactly why the field set is stated as checkable rather than fixed. Run the check against the version you actually run.

Two fields are the check worth running. deploymentMode and deploymentExposure tell you, from the instance itself, whether it is in trusted-local or authenticated mode, and whether its exposure is private or public.

What an anonymous caller sees depends on the mode. On an authenticated deployment, an unauthenticated caller gets the reduced body and does not see version or serverVersion. On a local_trusted deployment, an anonymous caller gets the full body, because there is no login boundary to redact behind. Run the check from outside your own network to learn which one you actually have.

Two smaller fields are worth naming. databaseBackup appears only where backup-health inspection is configured; it is not carried by default. And bootstrapStatus reports first-admin setup state, defaulting to "ready" where bootstrap does not apply, so "ready" is not on its own proof that a first admin was ever deliberately claimed.

What the check will not tell you

status exists on every response, and it is tempting to assume it only ever says "ok". At v2026.916.0 it can be "ok", "starting" while the server is mid-recovery, or "unhealthy" on a 503. At v2026.831.1, the version we first checked, a non-503 response could only say "ok". The "starting" value is new in this release, and it is a change our own draft had to catch rather than a hypothetical one.

The published OpenAPI schema has not caught up. It still enumerates only "ok" and "unhealthy" for that field, the same gap it already had for deploymentExposure, which the running server returns and the schema still does not list. Two separate reasons to check the running instance rather than the document describing it: a field the schema has never listed, and now a value the schema does not know the handler can send.

This is what we mean by governed and provably so, and it is the discipline we bring to a client's instance: the report says what the running system does, established against a named version, not what its documentation claims.

One limit worth stating plainly. The endpoint reports what the server believes about itself, not what your network actually enforces. It cannot see whether your reverse proxy, firewall or routing rules match what it reports. A correct deploymentMode sitting next to an open port upstream is a problem the health check has no way to find.

What hosting does not settle

Where Paperclip runs decides data custody, network exposure and backup ownership. It does not decide what the agents inside it can reach once they are working. The credentials an agent holds, the hosts its outbound traffic can reach, and whether an approval gate stands between a decision and its execution are governed at the runtime and policy layer, not by the hosting choice underneath. How to Harden Your Agent Runtime to Fail Closed and What Agent Run Isolation Means for Production Deployments cover that layer.

A well-hosted instance with an open egress policy has solved a different problem than the one it looks like it solved.

Start with the check, not the provider

Run GET /api/health against the instance you already have, before deciding anything about the instance you plan to stand up. It will tell you whether that instance is in trusted-local or authenticated mode, and whether its exposure is private or public. Set that against what you meant to configure. If they match, you know where you stand. If they do not, you have found the real question before touching the provider question sitting on top of it.

If you are weighing where to run Paperclip for real, or auditing an instance that is already live, that is worth a conversation with someone who reads your actual answer rather than a generic one. Book a call: thirty minutes, on what you are running and where it actually sits.