Lcl.host: fast, easy HTTPS in your local dev environment
1–10 of 101 posts
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#2I like the interactive setup. I think this is solid but if you want something even faster and easier to use, try my project localias [0]. The parent project, lcl.host, has some annoying restrictions:
> This CA has some restrictions though: it can only issue certificates for subdomains of lcl.host and localhost, but that’s all you need for local development.
Localias, on the other hand, lets you use any custom domain you'd like. And if you use a domain ending in .local, it will broadcast over mDNS so that you can easily connect to that server from any other device on your wifi network (like your phone.)
Localias also allows you to share your configuration with your entire development team by committing a .localias.yaml file to the root of your git repo. This makes sharing links with each other super convenient.
Always nice to see another competitor in the space; if you're interested in this, please check out Localias as well!
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#3It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just point a wildcard DNS entry at 127.0.0.1 or some other useful address if your dev copy is actually not that local, and chuck a web server there acting as a proxy to what-ever apps, with a LetsEncrypt wildcard cert. It isn't zero work, but saves time in the long run as soon as you hit unexpected issues caused by small differences between dev and prod.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#4How is this different from something like Caddy which supports https://localhost instead of something like https://lcl.host
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#5It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just point a wildcard DNS entry at 127.0.0.1 or some other useful address if your dev copy is actually not that local, and chuck a web server there acting as a proxy to what-ever apps, with a LetsEncrypt wildcard cert. It isn't zero work, but saves time in the long ru…
You don't even need to mess with a wildcard from Lets Encrypt, just use https://github.com/FiloSottile/mkcert
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#6It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just point a wildcard DNS entry at 127.0.0.1 or some other useful address if your dev copy is actually not that local, and chuck a web server there acting as a proxy to what-ever apps, with a LetsEncrypt wildcard cert. It isn't zero work, but saves time in the long ru…
> It surprises me how few people dev/test against HTTPS
For dev at least it’s mostly because web browsers treat localhost as a special domain that gets the HTTPS treatment even when loaded over HTTP.
I have set up local HTTPS certs before now, can’t remember exactly what required it. But I still load most web projects on localhost over HTTP just out of habit.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#7How is this different from something like Caddy which supports https://localhost instead of something like https://lcl.host
localhost gives you a different security context in your browser than using a full domain name. Typically to use a full domain name locally you'd either need to mess with /etc/hosts (which can bite you later) or mess with DNS. lcl.host just makes things work out of the box.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#8I don't see OrbStack mentioned here much, but it's completely replaced Docker Desktop for me. Aside from having a better UI, faster and uses less battery, it also gives local https with custom domains for free [0].
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#9How is this different from something like Caddy which supports https://localhost instead of something like https://lcl.host
localhost gives you a different security context in your browser than using a full domain name. Typically to use a full domain name locally you'd either need to mess with /etc/hosts (which can bite you later) or mess with DNS. lcl.host just makes things work out of the box.
Let me add a bit of clarification here, since you specifically asked about https://localhost
Using http with localhost is a mostly security context, but it has some quirks[0]. Using https://localhost will give you the full security context but then you're typically stuck either dealing with certs manually or using a proxy, like caddy. lcl.host should simplify your setup.
We're big fans of caddy by the way and even sponsor the project. Matt's doing amazing work over there.
Re: Lcl.host: fast, easy HTTPS in your local dev environment
#10It surprises me how few people dev/test against HTTPS, given that it isn't exactly hard to setup manually (with tools like this making it even easier). Just point a wildcard DNS entry at 127.0.0.1 or some other useful address if your dev copy is actually not that local, and chuck a web server there acting as a proxy to what-ever apps, with a LetsEncrypt wildcard cert. It isn't zero work, but saves time in the long ru…
You don't even need to mess with a wildcard from Lets Encrypt, just use https://github.com/FiloSottile/mkcert
I've always been a bit wary of a local trusted CA, especially with the signing cert on the same dev box as the certificates it signs which is how I've seen things done a lot. It feels like opening up a trust issue that could allow an uncooperative entity to play games with me… Maybe that is just paranoia from the practical jokes played back in CompSci at Uni!
Admittedly an external attacker getting close enough to sign a cert using such a CA, in order to trick me into something, means they probably have such high access already that they don't really need the CA to do that or worse, so perhaps it is unnecessary caution.