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.

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

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.

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

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.

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

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.

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.

I think that sounds reasonable, if you could update the remaining installers and references that'd be great

• Updated the PowerShell installer to match the new Caddy behavior.
• Removed the remaining Nginx references.

I also tested both the install.sh and install.ps1 paths for the localhost and domain configurations.

fixed couple other things, but should be good to merge to now