Hardening a Marketplace Install

Everything except the web interface is already closed. What stays open is Trinity itself: the web UI and the API answer anyone on the internet who finds the address, and your login is the only thing in the way.

Create an Arecord for the name you want, pointing at the droplet's IPv4 address, and confirm it resolves:

dig +short your-domain.com
# Expected: the droplet's IP address

Then, in Trinity: Settings → General → Public URL, enter the full address including https://, and save. No terminal step, no certificate to install.

What saving it does:

The certificate is obtained on the first request that arrives for the name, so visiting the site is what completes this step. Until someone does, Trinity says so: Settings reads saved, waiting for the first visit, and the first-run Secure this instance step shows Domain saved instead of Domain reached. (Saving alone marks that step done in the setup rail, so the step does not re-open.)

All three end with nothing listening on the public interface. They differ in who can still reach Trinity, and in what keeps working.

Tunnel only — everything keeps working, and the address answers anyone who has it, with your login as the only thing in the way. Enough while you are trying Trinity out.

Tailnet only — the interface is yours alone, and anything that calls in stops working. Pick it when nothing does.

Both — the tunnel carries what calls in, the tailnet carries you. Pick it if you use Telegram, WhatsApp, voice, public chat links, agent websites or webhooks, and you want the interface private. Follow Step 2a, then Step 2b, then Step 2c for the one setting that differs.

Everything Broken above is a third party making a request to your instance, which is exactly what a private network stops. Slack is unaffected because Trinity connects outward to Slack. Telegram is on the broken list because Trinity registers a webhook for it.

cloudflared runs beside Trinity and dials outward to Cloudflare; traffic arrives back down that connection.

The Cloudflare-side setup — creating the tunnel, the ingress rules, the DNS record — is identical on a marketplace droplet. Follow Public Access → Cloudflare Tunnel Setup, then return here for the two things that differ on this install.

1. Put the token in .env:

sudo nano /opt/trinity/.env
# add or edit:
# TUNNEL_TOKEN=eyJ...

2. Restart through the installer, not docker compose:

cd /opt/trinity
sudo ./scripts/deploy/start.sh --hosted

A non-empty TUNNEL_TOKEN is treated as intent: the installer starts the tunnel profile and records it in .env, so later docker compose ... stop and ... logs act on the tunnel too. This is the same command used to update the instance, so it is safe to re-run.

Trinity has no Tailscale integration — this is a host-level install that Trinity neither configures nor monitors. There is no one-click or invite mechanism to lean on: neither DigitalOcean nor Vultr lists a Tailscale app, and both apply marketplace images at create time only, so nothing can be added to a droplet that is already running. The install is two commands.

Reaching the web UI over a tailnet takes one setting — see Reaching the UI over the tailnet below, after the install.

Before you start, in the Tailscale admin console → Keys → Generate auth key: make it reusable, set an expiry (90 days is the maximum Tailscale allows), tick pre-approved if your tailnet has device approval on, and leave ephemeral off — ephemeral devices are removed 30–60 minutes after they go quiet, which would evict a server.

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up --auth-key=tskey-auth-XXXX --ssh --hostname=trinity
tailscale ip -4

--ssh matters: it is what still gives you a shell after the next step closes port 22, and it must be opted into per device.

Then turn off key expiry for this machine — admin console → Machines → the device's menu → Disable key expiry. New tailnets expire node keys after 180 days by default, and a server that silently drops off the tailnet with port 22 already closed leaves the provider's recovery console as the only way back in. This is a required step, not a nicety.

Only once tailscale ip -4 answers and you have confirmed you can SSH over the tailnet:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow in on tailscale0
sudo ufw delete allow 22/tcp
sudo ufw enable

Order matters — the tailnet rule has to exist before the deny takes effect. (Tailscale's own guide enables the firewall first and writes the delete without allow, which does not match the rule as added.)

Two more things specific to this image:

Worth knowing: a new tailnet's default policy lets every device on your tailnet reach this one, not only the laptop you joined from. And Slack is the one integration that survives this path, because Trinity connects outward to Slack over a WebSocket — though installing the Slack app the first time still needs a public address for the OAuth callback.

By default there is nothing to browse to once the public ports are closed, and one setting fixes it.

Why the default leaves you stranded.The web server picks which site to serve by the hostname in the request, not by the interface it arrived on, and it has exactly two: the droplet's public IP, which it holds a certificate for, and the domain you saved, which it obtains one for on demand. A tailnet address matches neither. Trinity is asked whether a certificate may be issued for it and answers no — that refusal is what stops your instance being an open certificate requester for anyone who points a name at it — and the connection fails. It could not succeed anyway: tailnet addresses live in carrier-grade NAT space, which no public certificate authority can validate. The saved domain does not help either, because public DNS resolves it to the address you just closed off.

The fix: serve plain HTTP to the private network. The VPN already encrypts the transport, so there is nothing for TLS to add. In /opt/trinity/.env:

PRIVATE_NETWORK_CIDRS="100.64.0.0/10 fd7a:115c:a1e0::/48"

Those two ranges are the ones Tailscale hands out, so they are correct whatever address your droplet ends up with. WireGuard, Nebula and ZeroTier use different space — use your own. Then re-render the web server's configuration:

cd /opt/trinity
sudo ./scripts/deploy/start.sh --provision --cloud digitalocean --caddy-only

--caddy-onlyrewrites the web-server config and nothing else. A plain restart does not pick the variable up, and re-running the full provisioning would also rewrite this instance's recorded address and install provenance, so it is the wrong tool for a one-variable change. The generated configuration is checked before the web server is reloaded — an invalid one leaves the running config alone rather than taking the site down.

Now http://<tailnet-ip> serves Trinity. Requests from anywhere else keep redirecting to HTTPS exactly as before.

The rule matches the source address of the connection, not a header, so a request from the public internet cannot claim to be local to get the login page in cleartext. Setting the value to 0.0.0.0/0 is refused for the same reason.

If you would rather not serve any HTTP at all, an SSH tunnel over the tailnet works with no configuration: ssh -L 8443:127.0.0.1:8081 root@<tailnet-ip>, then browse http://localhost:8443. The tunnel exits on the droplet as a local connection, so it needs no certificate.

Why you cannot just browse the container port. Trinity's container firewall drops anything reaching a container from off-box, tailnet traffic included, so http://<tailnet-ip>:8081 is dropped. Ports 80 and 443 work because the web server in front is a host process, and host ports never pass through those rules.

Do Step 2a and Step 2b, then change one thing about what the tunnel publishes.

In Cloudflare, publish paths rather than the whole hostname. Step 2a's quickest setup routes everything to the frontend, web interface included. Use the “Narrower: path-split rules” table in Public Access instead, and do not add the / catch-all row. The tunnel then carries webhooks, public chat links, agent websites and MCP, and has no route to the web interface at all.

Reach the interface over the tailnet, with PRIVATE_NETWORK_CIDRS set as in Step 2b.

You now have callbacks arriving over Cloudflare, the interface answering your devices only, and nothing listening on the public interface.

One thing to keep up. Connect a channel that needs a new inbound path and you have to publish that path too, or it stops delivering with no error here — the request never arrives. Verify after every channel you add.

To keep the interface public but behind a sign-in instead, Cloudflare Access challenges visitors before the request reaches the tunnel. It is set up on the Cloudflare side and their documentation covers it. Every machine caller then needs an exception, or it is challenged and fails.

Once the tunnel is connected, or you can reach the instance over the tailnet, add a cloud firewall blocking inbound 80 and 443. Leave 22 reachable from your own address only, or use the provider's console for shell access.

Run these as you go. If a check fails, do not close the ports — see Recovery.

The full six-probe check is in Monitoring — run it if anything above looks wrong.

Clearing the Public URL stops Trinity handing the name out, but if the address was also baked into the server's environment at install time, the web server keeps serving certificates for it. Settings then reads not configured while that is still true — change the environment value and restart if you need it genuinely gone.