The wrkr CLI
Ingress & custom domains — wrkr expose
Does the job you'd otherwise reach for Vercel, Netlify, or a tunnel to do.
wrkr expose takes a port your app is already serving on and puts it online at a
public HTTPS URL, with TLS handled for you.
wrkr expose --port 3000
# → https://<name>.apps.wrkr.dev (live, with TLS)
Because your machine is always-on, the URL stays up after you disconnect. This is how your app faces the internet.
When to reach for it
Any time you have something running locally on the box that should be reachable from outside — a web app, an API, a webhook receiver, a preview for a client.
Command reference
You'll usually just ask your agent; these are the exact commands it runs (and you can too).
wrkr expose --port <port> [--name <name>] [--json]
wrkr expose --port <port> --domain <app.example.com> [--json]
wrkr expose list [--json]
wrkr expose remove <host-or-name> [--json]
Full flags and examples: wrkr expose --help.
Your own domain
Pass --domain and wrkr expose prints the DNS record (a CNAME) to add at your
registrar. Once it resolves, your app is served on your own name with TLS:
wrkr expose --port 3000 --domain app.example.com
# → prints the CNAME to add; serves https://app.example.com once DNS resolves
You buy the domain from any registrar you like — that's one of the few things that genuinely stays external. Wrkr handles the certificate and the serving.
Managing routes
wrkr expose list # what's currently exposed
wrkr expose remove app.example.com # stop serving a route (by host or name)
What it is not
wrkr expose publishes a running port. It is not a build-and-deploy
platform:
- No git-push deploys, no build pipeline, no preview-deploy graph.
- No environment-variable console or runtime-logs dashboard.
That's by design. Your machine is your build-and-run environment — you (or
your agent) build and start the app on the box, and wrkr expose makes the
running thing public. For the full production story — keeping processes alive,
logs, domains — see Your apps in production.