Developer Tools

mkdev: Trusted HTTPS for Localhost Development

Silicon Valley has a knack for reinventing the wheel, often with a splash of unnecessary jargon. mkdev, a new open-source tool, tackles a persistent, infuriating problem for developers: getting trusted HTTPS on localhost.

Screenshot of the mkdev TUI interface showing mapped routes.

Key Takeaways

  • mkdev simplifies local HTTPS development by acting as a TLS reverse proxy, mapping named routes to dev servers.
  • It handles local CA installation, hosts file modifications, and dynamic certificate generation on the fly.
  • The tool supports local network sharing and aims to eliminate common browser warnings associated with self-signed certificates.

The laptop’s fan whirs, a familiar soundtrack to a developer wrestling with a stubborn configuration. We’ve all been there, staring at a browser warning that screams ‘Proceed (unsafe)’ after generating a self-signed certificate that feels more like a digital shrug than a solution.

For years, the localhost HTTP saga has been a low-grade fever for anyone doing web development. Plain HTTP breaks things. OAuth callbacks, those finicky gatekeepers of modern authentication, often demand https://. Secure cookies? Forget about it, they just won’t set. Service workers, the unsung heroes of offline functionality, refuse to register. And a whole host of SDKs? They just assume TLS is in play. Tools like mkcert do a decent job with the certificate part, but then you’re left playing whack-a-mole, wiring those .pem files and private keys into every single dev server you spin up, desperately trying to remember which port corresponds to which project.

Here’s the thing: <a href="/tag/mkdev/">mkdev</a> doesn’t just hand you a certificate. It sits one layer above that. You give a route a name, and poof, you get trusted HTTPS for that name. No more wrestling with individual server configs. No more deciphering cryptic error messages. It’s a refreshingly simple abstraction over a deeply annoying problem.

Who’s Actually Making Money Here?

This is where my cynical side kicks in. mkdev is MIT-licensed, meaning it’s free for the taking. The creators, Venkat Krishna et al., aren’t directly selling you a license. Their game, if you can call it that, is in building something genuinely useful for the developer ecosystem. The real win is adoption. The more developers that use mkdev, the more their contribution to the open-source world is recognized. Think of it as a really high-quality resume for the entire tech community.

On install, it whips up a local CA—an ECDSA P-256 root CA, no less—and sticks it right into your system’s trust store. It uses a clever trick, adapted from mkcert itself (kudos for crediting!), to integrate with macOS Keychain, Linux’s CA bundle directories, and Windows’ ROOT store. That’s the messy, OS-specific part, and reusing that code? Smart. Saved a ton of headaches.

Then there’s add <name> <target>. This little command does two crucial things: it logs your route (myapp.local mapping to localhost:3000, for instance) in a local database (~/.mkdev/state.db), and then, because we’re dealing with privileged operations, it mashes 127.0.0.1 myapp.local into your /etc/hosts file. It even uses a sudo-powered helper to do this atomically, which is a nice touch. No more manual host file edits.

The Magic of serve

The serve command is where the real conjuring happens. It hooks into 0.0.0.0:443 and, for every incoming hostname (via SNI, the savvy ones will know), it mints a leaf certificate on demand. This freshly minted cert, signed by your trusted root CA, is then used to decrypt the request before it’s unceremoniously shunted to your actual dev server, which is still blissfully chugging along on plain old HTTP. Your dev server never knows the difference. And the routes? They’re reloaded every couple of seconds, so adding or removing a mapping takes effect without a single restart. Slick.

But wait, there’s more! The tool also broadcasts these routes over mDNS, meaning you can actually test on your phone or a teammate’s laptop on the same network, hitting https://myapp.local without any of those gnarly browser warnings. Imagine testing mobile layouts on a real device, over actual HTTPS. It’s a feature that’s borderline luxurious, and frankly, long overdue.

Of course, it’s not all sunshine and roses. Firefox, that stubborn outlier, still uses its own certificate store and will grumble until you manually import the CA. And binding to port 443 requires root privileges, which some folks might find a bit much. You can always change the port to something like 8443 if sudo is too much friction. The sudo cache also expires, meaning you might get re-prompted for your password during mkdev add operations.

mkdev is a TLS reverse proxy, not a cert file generator. That distinction is the whole design.

That quote pretty much nails it. It’s not about generating files; it’s about providing a service. A service that makes local development just that little bit less painful. It’s the kind of tool that, once you’ve used it, makes you wonder how you ever lived without it.

Is mkdev Actually Better Than mkcert?

This is the million-dollar question, or rather, the free-open-source question. mkcert is fantastic at generating locally trusted certificates. It solves half the problem. mkdev takes that foundation and builds a whole house on top of it. It handles the routing, the dynamic certificate generation, the /etc/hosts management, and even the local network sharing. If you’re just generating a single certificate for a single project, mkcert might be enough. But if you’re juggling multiple local development environments, each with its own subdomains and specific HTTPS needs, mkdev is the clear winner. It’s less about generating certs and more about using trusted HTTPS fluidly across your entire local development workflow.

Will mkdev replace my job?

Unless your job primarily consists of manually configuring TLS certificates for every single local development server you use, then no, mkdev won’t replace your job. What it will do is free up your time and mental energy, allowing you to focus on the actual coding. By abstracting away the tedious complexities of local HTTPS setup, mkdev is a productivity booster, not a job eliminator. It’s the kind of tool that makes developers more efficient, which is precisely what you want in the tech world.


🧬 Related Insights

Frequently Asked Questions

What does mkdev actually do? mkdev is an open-source tool that provides trusted HTTPS for your local development servers. It acts as a TLS reverse proxy, mapping named routes (like myapp.local) to your running applications, ensuring secure connections without browser warnings.

How do I install mkdev? You can install mkdev using Homebrew (brew install venkatkrishna07/tap/mkdev) or by using Go (go install github.com/venkatkrishna07/mkdev/cmd/mkdev@latest). After installation, you run mkdev install to set up the local CA and then mkdev to launch the interactive TUI.

Do I need to run mkdev with sudo? By default, mkdev binds to port 443, which requires root privileges. If you prefer not to use sudo, you can configure mkdev to use a different port (e.g., 8443) by editing ~/.mkdev/config.toml and setting proxy_port = 8443.

Written by
Open Source Beat Editorial Team

Curated insights, explainers, and analysis from the editorial team.

Frequently asked questions

What does mkdev actually do?
mkdev is an open-source tool that provides trusted HTTPS for your local development servers. It acts as a TLS reverse proxy, mapping named routes (like `myapp.local`) to your running applications, ensuring secure connections without browser warnings.
How do I install mkdev?
You can install mkdev using Homebrew (`brew install venkatkrishna07/tap/mkdev`) or by using Go (`go install github.com/venkatkrishna07/mkdev/cmd/mkdev@latest`). After installation, you run `mkdev install` to set up the local CA and then `mkdev` to launch the interactive TUI.
Do I need to run mkdev with sudo?
By default, mkdev binds to port 443, which requires root privileges. If you prefer not to use `sudo`, you can configure mkdev to use a different port (e.g., 8443) by editing `~/.mkdev/config.toml` and setting `proxy_port = 8443`.

Worth sharing?

Get the best Open Source stories of the week in your inbox — no noise, no spam.

Originally reported by Dev.to

Stay in the loop

The week's most important stories from Open Source Beat, delivered once a week.