Replaced Nginx with Caddy

[rowin-C]

Relates to #3323

Description

Implements Caddy as a reverse proxy option for Puter, as requested in #3323.

Testing

Tested on a clean install from my fork — logs in successfully.

Note: the core logic has been shifted from nginx to Caddy, but there
are still mentions of "nginx" in the code (strings/
comments/variable names) that I haven't cleaned up yet. Will update
these before this is ready to merge.

To test:

curl -fsSL https://raw.githubusercontent.com/rowin-C/puter/feature/caddy-reverse-proxy/install.sh | \
PUTER_URL="https://raw.githubusercontent.com/rowin-C/puter/feature/caddy-reverse-proxy" sh

[ProgrammerIn-wonderland]

Hello, the advantage for caddy which was listed in the issue was automatic TLS certificate provisioning. I see that TLS is disabled in your PR, is there any reason for this? If it's going to be the same function as nginx regardless it would likely make more sense to keep with nginx.

[rowin-C]

you are correct, let me figure out the TLS certificate provisioning, then ill ask for an review.

[rowin-C]

The current configuration is intended for local development, so it uses HTTP by default, similar to the current Nginx setup. When a user is ready to deploy, they can replace the development block with their own domain and enable the HTTPS configuration. The difference is that with Nginx they also need to manually obtain and configure TLS certificates, whereas Caddy will automatically provision and renew them. TLS is automatic when the user will use a real domain.

If I'm misunderstanding something, please let me know. I really appreciate you taking the time to review this and bearing with me.

[ProgrammerIn-wonderland]

the main thing is if its http only it serves no additional benefit from what we already had, caddy isn't really superior for just proxying existing http only traffic. The advantages of caddy (to me atleast) are soley from the standpoint of the HTTPS verification, so if thats not enabled/working by default I just am not sure if its a good idea to switch the internal reverse proxy

[rowin-C]

That's a fair point. My initial goal was to keep the local development experience the same while making production deployments simpler with Caddy's automatic TLS.

Would you prefer the installer to prompt the user for a domain (or accept one via configuration) and then have Caddy automatically provision HTTPS for that domain? If so, I'm happy to update the PR in that direction.

[ProgrammerIn-wonderland]

By configuration sounds better in my view, maybe by some argument in the docker command line that both enabled TLS and configures the domain

[rowin-C]

I've updated the PR to use PUTER_DOMAIN to determine whether to generate a localhost or domain-based Caddy configuration.

Have a look when you have time.

To test:

Default (HTTP): run the installer normally (PUTER_DOMAIN defaults to puter.localhost).
Automatic HTTPS: set PUTER_DOMAIN to a real domain that points to the server before running the installer. Caddy should automatically provision the certificate.
PUTER_DOMAIN=cloud.example.com ./install.sh

If there are no issues with this approach, I'll follow up by updating the PowerShell installer and cleaning up the remaining Nginx references.