Guide · Launchpad 0.38.0 · about 20 minutes

Put your Gate on your own domain

Your instances answer only on your Mac until you say otherwise. This is how you give one a real address, using a Cloudflare tunnel that Launchpad creates and manages for you. No ports opened on your router, and your home IP address stays out of DNS.

What you are turning on

Browser  →  Cloudflare edge  →  cloudflared on your Mac  →  Caddy  →  your Gate

Cloudflare accepts the connection and ends the encryption at its edge. A connector running on your Mac dials out to Cloudflare and carries traffic back in, so nothing has to listen on your router. Launchpad manages the tunnel and one wildcard DNS record for it.

Publishing adds no sign-in of its own. It does not create a Cloudflare Access policy. Whatever you publish is protected only by the protection it already had — for Gate, that is Gate’s own login. Check that before you point a domain at it.

Before you start

A working local Gate. Do the local first run before this. Publishing a broken instance just puts the breakage on the internet.
A domain on Cloudflare, with its zone active on your account.
A Cloudflare API token with exactly three permissions: Account › Cloudflare Tunnel › Edit, Zone › DNS › Edit and Zone › Zone › Read, scoped to the account and zone you intend to use. Mint it at dash.cloudflare.com/profile/api-tokens.
The Cloudflare connector and a proxy on the machine that runs the server: cloudflared and caddy, with Caddy running.

brew install cloudflared caddy

Which machine? These go on the machine whose Launchpad server you are configuring — not necessarily the Mac in front of you. The app says which server it is about to change, and the token is saved to that server.

Choose the domain carefully

Cloudflare’s free certificate covers your domain and one level below it. So example.com and dash.example.com are covered, while chat.acme.example.com is not: it resolves and then fails with a certificate error, which reads like a broken feature rather than a certificate problem.

Gate puts its own parts on addresses below the host it is given, such as dash. and auth.. Public access gives each app <name>.<your-domain>, so a Gate named foo lands on dash.foo.example.com: two levels down, outside the free certificate, whichever domain you pick. Covering it needs Cloudflare’s Advanced Certificate Manager, a paid add-on this setup does not buy for you.

This path also forwards only the app’s exact address, not the deeper ones Gate uses, so do not expect a public Gate from it. For Gate, use one app on its own domain instead. The domain section on the main page explains which host costs what.

Doing it

Open Public access

In Launchpad, go to Settings → Public access. It names the server it is about to change, and shows how apps are reached today.

You should see the current access mode, and a choice of who manages the connection: keep it local, let Launchpad manage a tunnel, or route app hostnames onto a tunnel and proxy you run yourself.

Let Launchpad manage a tunnel

Pick Launchpad-managed Cloudflare Tunnel. It creates a new, dedicated tunnel for this. It will not adopt or rewrite a tunnel, DNS record or proxy configuration it did not create — if it finds one, it stops and tells you rather than taking it over.

Let it check the machine first

It checks that the connector and proxy are installed, that Caddy is running and reachable, and that no other connector already owns the same job.

You should see every prerequisite satisfied. Anything unchecked is a stop, not a warning — it would rather refuse than half-apply.

Save your Cloudflare token

Paste the token. It goes to the selected server, is stored with owner-only permissions, and afterwards only a hint of it is ever shown. Saving the token changes nothing at Cloudflare by itself.

You should see the token accepted, and the destination server named. Then Find domains reads the domains that token can manage. That read creates nothing.

No domains listed? The token is scoped to the wrong account or zone. That is a permissions answer, not an outage.

Pick the domain and read the exposure

Choose your domain and it previews the exact addresses: the one your apps will answer on, and the management hostname. Read that list properly — it is the whole point of the step.

You confirm two things by hand: that you have reviewed the public hostnames and the sign-in in front of each, and that you understand which existing public routes may be removed.

Apply, then prove it

Apply the change, then run the connectivity check. A saved setting is not a working address: saved, applied, restart-needed and verified are four different facts, and the app keeps them apart deliberately.

Then test it yourself from a device that is not on your network — a phone on mobile data. Open the real URL, check the padlock, and check that signing out actually locks you out.

Changing the domain can need the server restarted before sign-in works on the new addresses.

What ends up public

Address	What it is	Protected by
your app’s hostnames	Your Gate, and anything else you run on this server.	That app’s own login. Gate has one; check anything else.
the management hostname	Launchpad’s own control interface, on the internet.	Launchpad’s sign-in. Nothing else is added for you.

That management hostname is the part people miss. It is the reason to do this on a domain you are happy to expose, with a strong sign-in, and not on the family domain.

Going back to local

The same screen takes it back: choose local access and apply. Launchpad records the intent first, then disables the tunnel routes it created, removes the DNS records it created, clears the proxy routes it owns, and stops its own connector.

“Local” is a setting, not proof. Even after a clean withdrawal, test the old addresses yourself. Anything you or someone else created outside this setup — another connector, a stray DNS record — is not Launchpad’s to remove, and it will not remove it.

Sharp edges worth knowing

Edge	What to do
A certificate error on a deep hostname	The free certificate stops one level below your domain. Use a shorter domain, or buy Advanced Certificate Manager for the deeper names.
It refuses because something is already there	A tunnel, DNS record or proxy route it did not create. Look at that thing through whatever owns it. Do not delete it to make the setup pass.
Setup stopped halfway	It keeps the operation and its record. Reopen it and continue that one rather than starting a fresh setup, and never delete the record to clear an error — it is the evidence of what belongs to you.
Nothing answers after a reboot	The connector runs in your login session. The address works once you have logged in, so set Docker Desktop to start at login too, and expect a gap after a restart.
The check passes but the app is wrong	The health check proves the management path and version answer. It does not test your app’s URL, its certificate, or whether it is properly locked. Test each one.

One app on its own domain

There is a second shape: a single deployment owning a whole host, such as example.com, with its own tunnel and no management hostname exposed. This is the shape Gate needs. From Launchpad 0.46.0 it is in the Mac app:

Launch with an Own domain. The launch sheet has an optional Own domain field, and its preview shows the https address the app will use.
Publish it from the app’s overview. Its Own domain section shows the names the app owns, checks whether they answer, and has Publish and Unpublish.
Take the domain and every subdomain for Gate. Publishing can claim fewer names, but Gate answers on dash., auth. and more, and each one needs to reach it.

It needs the same Cloudflare token and cloudflared as above, but not Caddy: the tunnel goes straight to Gate.

This shape has been run with Gate on 0.47.0, from the command line, on a whole domain: Launchpad created the tunnel and the records for the domain and every name under it, and auth., dash., chat. and agents. answered publicly with a certificate that verifies. The bare domain answers 404, which is correct — Gate serves nothing there. Unpublishing removed everything it had created. The steps above are the app’s version of that route and have not themselves been walked with Gate.

← Back to Gate on your Mac