Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Caddy 2

caddyserver.com

Post reply on HN
Print view View original

221–230 of 247 posts

Re: Show HN: Caddy 2

#221

Post by StavrosK »

francislavoie wrote: post #192
pilif wrote: post #191

Earlier quoted context omitted.

I think the parent poster would already be happy with an APT repo provided by Caddy. It wouldn’t need to be included in Debian itself. When you can make dpkg files, making an apt repo is trivial (using reprepro shipped with Debian) And when it’s your repo, you make the rules about packaging what dependencies into which file(s) But by having an apt repo (that users would subscribe to), you make it much easier for user…

We do have one! https://caddyserver.com/docs/install#debian-ubuntu-raspbian

Oooh this is great news, I can finally quit updating Caddy by hand!

Re: Show HN: Caddy 2

#222

Post by guggle »

mholt wrote: post #14

Hi HN -- this is what I've been working on for the last 14 months, with the help of many contributors and the backing of several sponsors. (Thank You!) Caddy 2 is a fresh new server experience. Some things might take getting used to, like having every site served over HTTPS unless you specify http:// explicitly in your config. But in general, it will feel familiar to v1 in a lot of ways. If you've used v1 before, I r…

Just tried it by replacing NGinX on my personal servers... I don't have anything complex (python backends, some static files...) but so far the user experience is stellar :)

Re: Show HN: Caddy 2

#223

Post by asdkhadsj »

rubyn00bie wrote: post #188
lenkite wrote: post #169

For all the criticism of golang, the fact that it can be used to craft superb software like this is a testament to its real-world efficacy.

Sooo... you bring up something I could use some "learn me somes" on... golang. Recently, in my personal life when choosing a "next language" to learn I chose Rust over Go because it seemed to offer everything Go does, and then some (like them systems level programmings). However, at my current employer, Go has a solid following and I'm unlikely to sell Rust (or even want to[1]): could you please speak to that real-wo…

> For the org I am at, I don't believe, Rust offers much over Go for most of the use cases. Sure, it certainly can be _faster_ but who fucking cares?

That's actually not at all why I use Rust. I switched because I prefer the code locality. After ~5 years professionally with Go, I found large code bases were a pain point with Go because I never felt I had robust ways to solve problems, and instead always resolved to helper funcs. In Go it ended up being a ton of loops and helper functions. Spreading out the logic all over the damn place.

Go is still a great language, I'm not knocking it. I just don't think speed is a selling point for Rust, honestly. Memory control is. Enums and pattern matching is. Iterators are (my favorite thing about Rust).

Go could go a long way just having iterators.

Re: Show HN: Caddy 2

#224

Post by purerandomness »

Tomte wrote: post #220
purerandomness wrote: post #219

Earlier quoted context omitted.

A certificate can be issued for as many, or as few domains as you'd like. Look at certbot's -d parameter, this does not have anything to do with nginx, apache, caddy or any other web server.

Is that also possible when using --nginx? Or only in "vanilla" mode?

The nginx autoconfiguration plugin has no influence on how many domains the certificate you're requesting will be valid for.

Example: We run a SaaS on our client's domains, so for every client, we have to run `certbot -d subdomain.client1.com,client1.ourdomain.com,staging.client1.ourdomain.com,...`

That means we run certbot with ~4 domains (we include staging and other subdomains) for each client we have. This is highly automatable.

Whether you use nginx autoconfiguration or not is up to you.

Re: Show HN: Caddy 2

#225

Post by mholt »

networked wrote: post #208
mholt wrote: post #14

Hi HN -- this is what I've been working on for the last 14 months, with the help of many contributors and the backing of several sponsors. (Thank You!) Caddy 2 is a fresh new server experience. Some things might take getting used to, like having every site served over HTTPS unless you specify http:// explicitly in your config. But in general, it will feel familiar to v1 in a lot of ways. If you've used v1 before, I r…

Thank you for your work on Caddy! After a false start during the beta (mainly because of the missing documentation) I upgraded my personal websites from v1 to v2 RC1, and since then I have been a fan of the new version. Caddy 2 makes somewhat complex configuration more consistent and easier to express in the Caddyfile. The only thing I miss from v1 is the default handling of when static files are not found. I am very…

Yeah, Starlark is still on my list. It'd be a killer feature, but it's a huge project.

Re: Show HN: Caddy 2

#226

Post by Tomte »

purerandomness wrote: post #224
Tomte wrote: post #220

Earlier quoted context omitted.

Is that also possible when using --nginx? Or only in "vanilla" mode?

The nginx autoconfiguration plugin has no influence on how many domains the certificate you're requesting will be valid for. Example: We run a SaaS on our client's domains, so for every client, we have to run `certbot -d subdomain.client1.com,client1.ourdomain.com,staging.client1.ourdomain.com,...` That means we run certbot with ~4 domains (we include staging and other subdomains) for each client we have. This is hig…

I don't understand you.

Does the nginx autoconfiguration allow separate certificates, or do you simply say "don't use that"?

Re: Show HN: Caddy 2

#227

Post by nikisweeting »

francislavoie wrote: post #47
nikisweeting wrote: post #36

YESSS so happy there's now an apt install method: echo "deb [trusted=yes] https://apt.fury.io/caddy/ /" | sudo tee -a /etc/apt/sources.list.d/caddy-fury.list apt update && apt install caddy

Yay! That was my pet project for the past couple weeks, I'm so glad to see people appreciate it!

Thank you so much for investing the time to do it, this was the only thing holding me back from using Caddy for everything over the last ~2 years. I know it's a painful process for Go packages in particular, but it's definitely worth it to be more easily installable for diehard apt users like myself.

Re: Show HN: Caddy 2

#228

Post by nikisweeting »

francislavoie wrote: post #57
buttersbrian wrote: post #35

and does it currently work with python apps that work via wsgi?

There's no wsgi transport built-in, we haven't found any golang libraries that let us do this yet. For now, until we find a solution, we recommend using something like gunicorn and use the `reverse_proxy` directive in Caddy to proxy to it.

I'm no *SGI expert, but ASGI might be easier to bridge with the Golang-style concurrency-model than WSGI. Not sure if there are any libraries for goASGI yet though.

Re: Show HN: Caddy 2

#229

Post by purerandomness »

Tomte wrote: post #226
purerandomness wrote: post #224

Earlier quoted context omitted.

The nginx autoconfiguration plugin has no influence on how many domains the certificate you're requesting will be valid for. Example: We run a SaaS on our client's domains, so for every client, we have to run `certbot -d subdomain.client1.com,client1.ourdomain.com,staging.client1.ourdomain.com,...` That means we run certbot with ~4 domains (we include staging and other subdomains) for each client we have. This is hig…

I don't understand you. Does the nginx autoconfiguration allow separate certificates, or do you simply say "don't use that"?

No no, you should totally use separate certificates (for our SaaS that's crucial, otherwise we would let our competitors know who our entire client base is, if all the domains would be included in one certificate)

I don't know too much about certbot's nginx plugin, I don't use it and don't see the benefit to be honest, we ran into problems with it (it didn't work for us because our clients have to set up a CNAME DNS entry, and that domain has to be included in the certificate)

We simply run certbot without the nginx plugin, and then have a config template for new virtual servers in nginx, based on a template. Certbot's nginx plugin would mess with our config constantly, changing from version to version, leaving artifacts, and we didn't like that.

Re: Show HN: Caddy 2

#230

Post by Tomte »

purerandomness wrote: post #229
Tomte wrote: post #226

Earlier quoted context omitted.

I don't understand you. Does the nginx autoconfiguration allow separate certificates, or do you simply say "don't use that"?

No no, you should totally use separate certificates (for our SaaS that's crucial, otherwise we would let our competitors know who our entire client base is, if all the domains would be included in one certificate) I don't know too much about certbot's nginx plugin, I don't use it and don't see the benefit to be honest, we ran into problems with it (it didn't work for us because our clients have to set up a CNAME DNS…

Thanks for the advice! I'll look at it all on the weekend.
Post reply on HN