# One-click paths

> Eleven ways to deploy a Weald relay without writing a compose file: a VPS, Hostinger, Render, Fly, Railway, DigitalOcean, Coolify, Dokploy, CapRover, Umbrel, or your Mac.

Source: https://getweald.com/docs/self-hosting/one-click
Last modified: 2026-08-24

---

## Eleven places

Last updated 2026-08-24

There are eleven places you can put a Weald relay without writing a compose file, and the deploy page is the grid of them, one link each. This page is the same list with the reasoning attached: what each provider runs for you, what it costs you in control, and the one step that goes wrong on all of them.

Every path installs the same published image, pinned to the same digest, with the same three required settings. A provider choice changes who runs the database and who holds the certificate. It never changes the relay, and it never changes what the relay can read, which is nothing.

## Which one to take

*Choosing a path*

| You have | Take | What the provider runs |
| --- | --- | --- |
| A VPS you are about to create | Paste cloud-init.yaml into the user-data box | Nothing, the bundle brings it |
| A Hostinger VPS | Docker Manager, pointed at our compose file by URL | Nothing, the bundle brings it |
| A Render, Fly, Railway or DigitalOcean account | That provider's template | Postgres, storage, TLS |
| Coolify, Dokploy or CapRover already installed | Paste the artifact for it | Its own reverse proxy and certificates |
| A box at home | Umbrel, or the compose bundle | Nothing, and there is no public ingress |
| A Mac and no server | Weald Relay Host | Docker on your Mac |

The provider-template row is the one worth thinking about. It hands Postgres and object storage to the provider: their backups, their durability, their bill, which is usually what a team wants, and also a managed service you did not read the source of. The compose bundle is the opposite trade on both counts.

## The step that goes wrong

First boot prints a one-time enrollment URL, once. On a one-click path the only place it appears is the provider's log view, and that is the view people close.

The URL lives for 24 hours and can be reissued while the workspace has no trust root yet:

```sh
docker compose exec relay wealdrelay bootstrap --reissue
```

Once a device has claimed it, reissue refuses, permanently. That is the workspace trust root being real rather than resettable, and it is why the first device to open that URL should be the Mac you intend to administer the workspace from.

The cloud-init.yaml and StackScript paths write the URL to /root/weald-enrollment.txt as well, because on those paths nobody is watching a log view.

## What none of them will do

No path gives you an admin panel, an operator account or an admin password, because there is nothing an operator could usefully administer. Members are admitted in the client, signed by a device that holds the right to admit. An operator who is not a member of the workspace cannot add one, read one, or see who they are.

No path weakens the access set. WEALD_RELAY_ACCESS_SET=enforce is set by every artifact and none of them offer a switch. The single place off is defensible is a private network with no public ingress, which is a decision you make in configuration and which every member's encryption panel then shows.

No path publishes the observability listener. Metrics and readiness are on port 9090, bound where only the machine can reach them.

## Before you invite anybody

Set up backups. On a provider-template path this is the provider's backup feature and you should turn it on rather than assume it. On the compose paths it is a pg_dump and a copy of the bucket, and it is the step this documentation puts before the invite rather than after it because it is the one people skip.