When LocalCan 1.0 shipped, it did one thing: gave your local apps a .local domain you could trust. v2 added Public URLs so you could share your work-in-progress with the outside world.
Today's release is a different scale of jump. LocalCan 3.0 Beta is the biggest update we've ever shipped — fully rewritten, with a daemon architecture, new infrastructure, a new configuration model, and broader platform support. Everything we wanted to improve in v2 is now in this release.
Here's what's new.
A real CLI
localcan is now a proper CLI. Open a terminal, point it at any port, and you have a Public URL:
localcan http 3000
That's it. You'll see the local domain, the Public URL, and a live request log right in your terminal. Hit Ctrl+C to stop.
Beyond the quick-tunnel commands, the CLI exposes the daemon, your projects, your services, your tunnels, and your license:
localcan tunnel ls
localcan services ls
localcan license activate localcan_xxxxxxxx
localcan reload
Every command speaks JSON when you ask it to (--json), so wiring LocalCan into CI scripts, dotfiles automations, or your own tooling is straightforward.
The same interface lets AI coding agents drive LocalCan directly. An agent can scaffold an app and run localcan http 3000 to expose it for a preview link, webhook testing, or OAuth setup — no human in the loop to click around the desktop GUI. Especially handy in headless or sandboxed dev environments where the agent has no screen to share.
A global edge network
In v2, Public URLs went through servers in Amsterdam. If your client was on the other side of the world, traffic had to cross it twice — once to LocalCan's edge, once back to your laptop. The result wasn't always great.
v3 ships behind a global edge network. LocalCan picks the closest reachable edge, then talks to it directly. For users with verified custom domains, the backend pins the closest edge per domain, so latency stays consistent across reconnects.
Day-to-day this means faster page loads, snappier API responses, and demos that don't feel like they're stuck behind a 300 ms round trip.
Configuration as code
The desktop app's project list is now backed by plain YAML files under ~/.localcan/projects/. One file per project, version-control friendly, hand-editable:
name: My App
services:
web:
target: http://localhost:3000
endpoints:
- provider: localcan
url: dev.example.com # Public URL (tunnel)
- url: my-app.local # local .local domain
Drop the file in, run localcan reload, and the daemon picks it up without dropping connections to projects you didn't touch. Keep these in dotfiles, share them with teammates, or store them next to the app they describe — a dedicated "external project" pointer that lets you keep the YAML inside your app's own repo is in development for a future release.
Linux support
LocalCan finally runs on Linux. It's CLI-only — no desktop UI on Linux today — but the same localcan binary, the same daemon, the same Public URLs:
curl -fsSL https://localcan.com/install-beta.sh | sh
A few things behave differently on Linux. .local resolution depends on your system DNS instead of Bonjour, and traffic inspection is desktop-only for now. Everything else works the same.
Multiple endpoints per service
A service in v3 can be reachable at more than one URL. The most common shape:
services:
web:
target: http://localhost:3000
endpoints:
- url: my-app.local # local domain
- provider: localcan
url: my-app-12.localcan.dev # Public URL
- provider: localcan
url: preview.example.com # custom domain
basic_auth:
- "preview:demo123"
Three URLs, one service. Use the .local while you're working, the *.localcan.dev URL for ad-hoc sharing, and the custom domain for stakeholders. Headers and basic auth are configured per endpoint and apply only there. Traffic inspection covers all three.
What's removed
Cloudflare Quick Tunnel integration is gone. v2 supported it as a second tunnel provider, but we've focused 3.0's tunnel stack on LocalCan's own infrastructure to deliver the speed and reliability story above. If you relied on Cloudflare Quick Tunnels in v2, switching to a Public URL on *.localcan.dev or a custom domain is a one-line YAML change.
A note on upgrading
LocalCan 3.0 Beta installs alongside 2.x and leaves your existing data intact. The first time you open it, a dialog asks how much to migrate — the default ("license only") is reversible, so you can keep 2.x as a fallback while you try out 3.0. Migrating Public URLs is the only one-way decision: once a URL runs on 3.0's new infrastructure, it can't go back to 2.x (contact support if you're in this situation).
Try the beta
- macOS and Windows: download from localcan.com/download↗
- Linux:
curl -fsSL https://localcan.com/install-beta.sh | sh - Docs: Installation, CLI quick start, Configuration
I'd love your feedback while it's in beta — the bugs you hit, the features that surprised you in a good way, and anything that didn't quite click. Drop a line at beta@localcan.com↗.