Gate × Launchpad — alpha
Gate is the intelligent operating system that runs your business. This page is about running your own copy of it: on your machine, in Docker, under your control. Bring up two and watch them talk.
Launchpad is the app that installs and runs Gate on your Mac. You download Launchpad; it builds and starts Gate for you.
Wondering how to use AI for your business? Try Gate — start at gate.software.
Launchpad 0.62.1 is available now.
Any Mac on macOS 15 or later · Docker Desktop required.
Before anything else
Two quick questions, so nobody spends an afternoon on an install they cannot use.
Gate is the intelligent operating system that runs your business. If you have never seen it, start there rather than here — running your own copy makes sense once you know what you are running.
Go to gate.software ↗This alpha is for Gate subscribers. Without one there is nothing to sign in to and the instance you build has no plan behind it.
Check your account ↗Both yes? Keep going — the rest of this page is for you. The alpha itself goes out to a small group, so being a subscriber makes you eligible rather than automatically enrolled.
Before you start
Check these first. Launchpad will not install any of them for you, and it will tell you plainly when one is missing rather than failing halfway through.
Apple Silicon or Intel — the app is a universal binary, so both work. Earlier versions of macOS are not supported.
One Gate, measured on an Apple silicon Mac: about 4.4 GB of Docker images and 130 MB of data on disk, and about 840 MB of memory while it sits idle. Give Docker room beyond that — 8 GB of disk and 2 GB of memory is a comfortable start.
Your Gate instances run as Docker containers. Start Docker before you launch.
Gate’s source is private. Your GitHub account needs access to it, and the Git credentials on your Mac have to reach it — Launchpad clones with yours, not with an account of its own.
Four to five minutes on an Apple silicon Mac, once Docker has the base images. It compiles the interface and bakes everything into one image, so later launches reuse most of that work.
Those figures are from a single instance. A second one adds its own containers and its own data; whether it also rebuilds the image depends on the source you give it, and that has not been measured yet.
Get Launchpad
A Mac app, or the same control plane from a terminal. Both are macOS only.
A signed, notarized disk image. Open it and drag Launchpad to your Applications folder. Everything it needs is inside: there is no Bun or Node.js to install separately.
Download Launchpad 0.62.1
0.62.1 · build 260926001 · 28 September 2026 · 70.4 MB
macOS 15+ · Apple Silicon or Intel · 169 MB installed
sha256 cf002e9a873c88c7db0a7e674ba9cf4b7e027b9d2432daf1a74c05d2ca177efd
The same control plane, driven from a terminal. The published binaries are signed and notarized, like the app.
curl -fsSL https://download.launchfile.io/launchpad/install.sh | sh
It drives a Launchpad server; it does not start one. With the Mac app installed, point it at the built-in server:
export LAUNCHPAD_SERVER=http://127.0.0.1:3210
On a machine with no app, --with-server installs the server alongside it.
The installer checks the published checksum of everything it installs and stops if one
does not match.
0.62.1 · macOS, Apple Silicon or Intel · Developer ID signed, notarized
versioned apart from the app, which is 0.62.1
There is still nothing to install. The Linux builds are not published: the installer asks for the Linux name and stops on a 404, so it fails loudly rather than installing something wrong.
The open-source launchfile tool can run Gate from a
copy of Gate’s source, and that path has been run end to end here. It needs access to
Gate’s private repository, like every other path on this page. Ask from inside
Gate.
This is an alpha. It is signed and notarized, so it opens without Gatekeeper warnings, but it has had little use. Keep nothing irreplaceable in an instance you create with it.
Your source
Launchpad builds from a repository and a ref that you pick. It does not quietly swap your source for someone else’s.
Point Launchpad at your own fork if you have one. The repository, the branch or tag, and the exact commit it resolved to all stay visible on the instance afterwards.
Refreshing or updating keeps the source you chose. Moving to a different fork or ref is a deliberate, separate action — never a side effect of an update.
One line, pasted into Launchpad as the source:
https://github.com/vwallander/GATE
Gate’s launch profile is on its main branch, so the repository itself is the source. That branch moves — fixes land on it daily. Launchpad records the exact commit it resolved to, so you can always see which one you are running. The repository is private: if you cannot clone it, that is access, not a bug.
Your first run
This is the whole journey. It is worth doing in order — the second instance is the interesting one.
Check what you need on the machine, start Docker Desktop, then download Launchpad. Open the disk image and drag Launchpad to your Applications folder.
The app carries its own server. Give it a moment on first launch, and approve the permission prompts it explains as it goes.
Give it a name, point it at your repository and ref, and start it. The first build is the slow one — it clones, provisions, bakes an image and boots.
Launchpad captures a one-time setup link. Open it in a browser to sign in as the instance’s first administrator.
Treat that link like a password. Opening it shows a sign-in page. Confirming on that page is what spends it: you become the first administrator, and every other setup link for that instance stops working for good. Do not paste it anywhere, and do not probe it to “check” it. Asking Launchpad for a fresh link cancels the one before it.
Same source, its own name. It gets its own database, its own storage and its own secrets — it is a genuinely separate instance, not a second window.
Complete its first admin login independently, then exercise communication between the two through Gate’s own features.
Running two isolated instances side by side is still being proven. Until that work lands, this page must not promise it. Nobody should read “Launch a second Gate” as tested.
Where it answers
Local is the default and needs no domain, no DNS and no certificate. A public domain works: Gate has been run on one, once, from the command line. Read how Gate uses a domain before you point one at it.
nothing to configure
foo answers on addresses like
https://dash.foo.lvh.me:<port>. lvh.me is a public
name that points every address under it back to 127.0.0.1, your own
machine. There is nothing to buy and nothing to set up.through a Cloudflare tunnel
cloudflared installed.One thing to know before you publish a whole server. That mode also
puts launchpad.<your-domain> on the internet — Launchpad’s own
management endpoint. Its sign-in still applies, but the door is now a public one.
Publishing a single app to its own host does not do this.
Launchpad refuses to take over a tunnel, a DNS record or a proxy configuration it did not create. That is deliberate: it would rather stop than quietly rewrite something of yours.
Not a newly bought one, but Gate needs a host that is its own. Gate is not a
single address. It gives itself a set of addresses under the host it is given —
dash., auth., api., agents. and more
— and one sign-in covers all of them. Nothing else should live under that host.
Where you put Gate decides what the certificate costs. Cloudflare’s free certificate covers your domain and one level below it. Deeper addresses still resolve, then fail with a certificate error that looks like a broken feature.
| Gate’s host | Its addresses | Free certificate? |
|---|---|---|
| foo.lvh.me local |
dash.foo.lvh.me |
Not needed. Nothing leaves your Mac. |
| example.com a whole domain |
dash.example.com |
Yes for the main addresses. Organisation sites sit one level deeper
(docs.acme.example.com) and are not covered. |
| gate.example.com a subdomain |
dash.gate.example.com |
No. Every address needs a paid certificate. |
| foo.example.com an app under Public access |
dash.foo.example.com |
No, for the same reason as a subdomain. |
So the cheapest public Gate owns a whole domain, and a spare domain is ideal.
On a subdomain you need Cloudflare’s Advanced Certificate Manager on that zone, with a
certificate pack for *.gate.example.com. Its automatic Total TLS option does not
issue certificates for addresses behind a Cloudflare tunnel, and a tunnel is how Launchpad
publishes.
what it takes
cloudflared on the machine that runs the Launchpad server. Public
access also needs caddy.This has been run, on 0.47.0 or later, from the command line. Gate was
launched with a whole domain as its own host and published with the default names: the
domain itself and every name under it. Launchpad created the tunnel and both DNS records,
and from the public internet auth., dash., chat.
and agents. all answered with a certificate that verifies. Unpublishing
removed the records, the tunnel and the connector, and left the zone’s other records
alone.
The domain itself answers 404. Gate serves nothing at the bare name, so that is the expected answer, not a broken setup.
Untested, so do not assume: Gate on a subdomain, where its names sit two levels down and need a paid certificate; publishing only some names instead of all of them; and doing any of this through the Mac app’s Own domain field rather than the command line. Earlier releases cannot do it at all — 0.47.0 is the first with the fix that lets Gate finish starting.
Public access is a different thing and not this route. It gives each app
<name>.<your-domain>, and forwards only that exact address, not
the deeper ones Gate uses.
The steps themselves are Launchpad’s Gate quickstart, which is not published on this site yet. If you want a public Gate now, ask from inside Gate.
What runs where
They are not the same program and they do not have the same reach. It is worth knowing which is which before you install either.
runs on your Mac
runs inside containers
127.0.0.1, so they answer
on your Mac and not to the rest of your network.Questions
Gate is the product — the workspace you actually use. Launchpad is the tool that puts it on your machine: it clones the source, builds an image, starts the containers and hands you a link. You can run Launchpad without ever using Gate, and Gate exists happily without Launchpad. This page is about using the one to get the other.
It controls Docker. Anything Docker can do on your machine, Launchpad can ask it to do — create containers, mount paths into them, make networks and volumes, remove them again. That is a lot of access, and there is no way to build and run arbitrary apps without it.
It also reads the repository you point it at, using your existing Git credentials, and registers a small background service so its own server can run while the app is closed.
Only what its container has. Gate runs in Docker, so it does not see your home folder, your keychain or your other files. Its database, cache and uploads live in volumes that belong to that instance, and a second instance gets its own.
Launchpad does not talk to Gate’s master. It builds and runs things on your machine; it is not part of Gate’s network.
Gate can join a fleet, which is how house rules and billing reach an instance, but that takes an enrolment token you provide. An instance you launch here is not enrolled unless you enrol it.
Both of them do reach the ordinary internet while working — cloning your repository, pulling base images, and checking this site for a newer Launchpad.
Not unless you ask for it. Instances Launchpad creates bind to 127.0.0.1,
which answers only on your own Mac.
Publishing one to a domain is a separate, deliberate step that you start. After it, the instance is on the internet — see on your own domain.
Publishing a single app puts that host and everything under it —
gate.example.com and *.gate.example.com — on the internet.
Publishing a whole server’s routing puts *.example.com there
and launchpad.example.com, which is Launchpad’s own management
endpoint.
Publishing adds no sign-in of its own. Whatever you publish is protected only by the protection it already had, so check that before you point a domain at it.
From 0.42.1, yes — but only when you tell it to. It never checks on its own and never installs anything unattended. When you choose Install, it closes its built-in server, backs up its control state, replaces the app and restarts. Your apps keep running throughout.
Coming from 0.38.0 or earlier? Those versions can only tell you an update exists. Download the current release from this page and replace the app yourself, once; later updates can install from inside the app.
Measured with one instance on an Apple silicon Mac: 4.4 GB of Docker images, about 130 MB of data to start with, and 840 MB of memory at idle across its four containers. The first build took four to five minutes.
Most of that disk is one image holding Gate and everything it needs. Removing an instance frees its containers and data, but the images stay until you remove those separately — a tidy-up worth knowing about if disk is tight.
No, and this surprises people. Your Gates are Docker containers, and containers keep running when the tool that started them closes. Quitting Launchpad closes the window, not the instance. Stop them from Launchpad, or with Docker directly.
Stop and delete your instances from inside Launchpad first — that removes their
containers and volumes, which is where the data is. Then drag
Launchpad.app to the Bin.
Two folders hold its own state and are not removed with the app:
~/Library/Application Support/Launchpad and ~/.launchpad.
Delete those to leave nothing behind.
No. It is an alpha: signed and notarized so it installs cleanly, but lightly used and without backups or a support contract. Treat anything you create with it as disposable until that changes.
What happens to a running local instance if a Gate subscription lapses is not documented here yet. It should be, because it is the question someone asks after they have put a week into one.
Known limitations
Read this before you install. An alpha that hides its edges wastes your afternoon.
Release notes
build 260926001 · Launchpad server 0.62.1
Gate starts on every server. An app’s own Redis or database is
now reachable only from that app, on every server, so Gate no longer hangs at start on a
server installed with --with-server. The command line is 0.62.1 too.
Launches run in the background. Launching Gate through Cloudflare no longer fails after about 100 seconds while the image is still building.
Public access: pick your tunnel and DNS style. Adopt a Cloudflare tunnel you already run on this Mac, or let Launchpad manage one. DNS can be one record per app (the default) or one wildcard, and you can switch later without a gap.
DNS is checked before a launch. If a record sends the app’s names somewhere else, the launch refuses and names the record.
Also: the command-line tool finds the server’s secret by itself on this Mac, and relaunching an app from a different repository under the same name is refused. The full release notes list the rest.
build 260923001 · Launchpad server 0.52.0
Apps that answer at more than one name. A Launchfile can now list the
names an app answers at, and Launchpad routes every one of them or refuses the launch
before creating anything. On a domain you own, it can put such an app on the apex and
publish exactly those names — dash., auth. and the rest
— while leaving the bare domain alone.
Your own domain, your names. On it, api,
www, admin, mail and auth are yours
to use. Only launchpad and localhost stay reserved.
Watch out for: names two levels below the app’s own host are refused. A name deeper than Cloudflare’s free certificate reaches is still routed, and the routing step tells you it is not covered. The full release notes list the rest.
build 260919001 · Launchpad server 0.50.0
Your own domain, from the app. The launch sheet takes your Cloudflare token and says so plainly when one is missing. The guided public-access setup now finishes on the built-in server, and an empty workspace offers it before you launch anything.
Delete an app from Launchpad. It asks you to type the app’s name, then removes the app and its data.
A command-line tool, covered above.
Also: each app shows its address in its header, the server card says how your apps are published, and withdrawing an app deletes its Cloudflare tunnel. The full release notes have the rest.
build 260918001 · Launchpad server 0.47.2 · Launchfile 0.10.0
Two update fixes. After an update finishes, the next one can be installed without quitting and reopening the app first. Launchpad also comes back to the display and position it had before the update.
Everything else matches 0.47.0. The full release notes list it.
build 260917006 · Launchpad server 0.47.0 · Launchfile 0.10.0
Gate starts reliably. An app that brings its own Redis could hang while starting and never finish. Gate is such an app, so this is the release that made a public Gate possible at all.
A walked Gate quickstart, local and on a public domain — the run behind the domain section.
Smaller repairs: the launch address is a choice rather than an editable default, a slow Docker is reported as slow instead of missing, the built-in server runs at normal priority, an update install finishes even when the old port is briefly still held, routing accepts an account-wide Cloudflare token, and a generated backing service stays on its own app’s network.
The full release notes have the rest.
build 260917005 · Launchpad server 0.46.0 · Launchfile 0.10.0
Launch an app on your own domain. The launch sheet has an optional Own domain field, and the address preview shows the https address the app will use. If the server refuses a domain, it says why right there.
Choose which names a published domain takes: the domain itself, every subdomain, or labels you name. Before, publishing always took the domain and all of its subdomains.
Each app’s overview has an Own domain section showing the names it owns, a live reachability check, and Publish or Unpublish.
Updates finish on their own when Launchpad restarts after installing, instead of waiting for you to open it again.
Watch out for: own domains need a server that supports them. The built-in server does; a server you connect to by address needs Launchpad 0.45.0 or later. A public Gate has been run one way only — see the domain section. The full release notes list the rest.
build 260917004 · Launchpad server 0.42.1 · Launchfile 0.10.0
Launchpad can install its own updates. Choosing Install closes the built-in server, backs up its control state, replaces the app and restarts it. Apps you have deployed keep running throughout.
Nothing happens behind your back. The app still never checks for updates on its own, and every install starts from you choosing Install. If an update was interrupted, Launchpad resolves it at startup before its server may start.
Fixes underneath: generated configurations are hardened and Redis now requires a password, sensitive Launchfile outputs are masked before they are stored, and every recursive delete is checked so it cannot reach outside Launchpad’s own folders.
Watch out for: an install cannot be undone once it begins, 0.38.0 cannot install this update for you, and deletion is still disabled in the app.
build 260916001 · Launchpad server 0.38.0 · Launchfile 0.10.0
You can now put an instance on your own domain. The app has a guided setup for how its server is reached: keep it local, let Launchpad manage a Cloudflare tunnel for you, or point it at a tunnel or proxy you already run. It checks what it needs before it changes anything, saves your token deliberately rather than silently, and can pick a half-finished setup back up where it stopped.
Checks are tied to what is actually configured now. A verification from before you changed your domain or tunnel no longer counts as a current one.
Fixes underneath: new Cloudflare tunnels, HTTPS upstreams, backing services coming back after a reboot, and environment values scoped to one component. The app catalog, settings labels, empty states and the built-in console all got a pass.
Nothing extra to install. The bundled server carries its own Bun runtime, so no separate Bun or Node.js is needed. Docker is still required to run anything.
Watch out for: updates that do not install themselves, deletion still disabled in the app, and the fact that a signed, notarized package proves the download is genuine — not that Cloudflare setup or a two-instance Gate run has been proven on your machine.
Quitting the app does not stop its server, and stopping the server does not stop your containers. Both are deliberate; use the app’s server controls to stop the first.