OpenCan started from a simple frustration: local HTTPS is still more manual than it should be. OAuth flows expect it. Secure cookies depend on it. Browsers increasingly assume it. Yet getting there locally usually means stitching together certificates, reverse proxies, trust chains, and host resolution just to make an app behave normally.
Making local HTTPS feel native
The goal with OpenCan was not to paper over certificate warnings. It was to make local HTTPS feel like infrastructure instead of setup. Add a domain, point it at a local service, and let the rest fall into place. Certificates, local resolution, and proxying should not be the interesting part. They should just work.

That shaped the architecture early. The core is a Rust daemon that handles certificates, TLS termination, proxying, domain routing, and the local system integration needed to make those domains resolve cleanly. On top of that sits a native macOS control layer so the whole thing does not feel like a pile of scripts with a thin UI added later.
Local infrastructure should feel a lot closer to the real thing.
From utility to edge layer
OpenCan gets more useful once it stops being a localhost wrapper and starts acting like a small local edge layer. The daemon does more than terminate HTTPS. It manages domain mappings, reloads configuration without tearing itself down, and treats the local environment as something worth modeling properly.
That is also where features like auth, access control, and tunnel support start to make sense. The bigger benefit is that the whole local environment becomes easier to trust and test.

Why Rust made sense
Rust fit because the hard part of OpenCan is systems work. Long-running processes, TLS, sockets, proxy behavior, certificate generation, and hot-reloaded configuration all benefit from something fast and predictable. The native macOS layer keeps the surface approachable, but the core of the project stays intentionally close to the metal.
That split matters. The app should feel simple even if the implementation is not.
What I would push further
The next step is extending the idea without making it feel bloated. Tunnels, better auth flows, and stronger support for protected local environments all fit naturally here. The hard part is keeping the main experience clean while the system underneath gets more capable.
