Replies: 1 comment 1 reply
-
@sandstrom I think that's the right idea: proxy the local server through Caddy. Puma's not really something that's easy to drop unless you are only concerned with the static output. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
We're using Caddy in front of Bridgetown in production. Works great!
In development we aren't using Caddy though, mostly because we haven't needed it so far.
But we're running into some things around ENV variables, where we need to make the site more configurable from the outside (12-factor etc). Partly related to docker and how we want to use the same docker image in development and production. Caddy provide template run-time overrides based on ENV variables, which are useful for this.
So, I'm wondering, how difficult would it be to run Caddy (or any other webserver) in development too, in front of Puma I'd guess (still retaining auto-reload on file changes, etc)?
EDIT: Maybe it's as simple as making our own wrapper script that starts Caddy, and then invoking
bridgetown start
under the hood, and set it as the upstream/proxy that Caddy should use?Maybe long term, bridgetown could have an approach similar to what I proposed here[1], regarding front end frameworks: that it provides some contracts/expectations on e.g.bridgetown start
, and then it's configurable what processes should start when running that command.Just wanted to open up the discussion around this though.[1] #609 (comment)
Beta Was this translation helpful? Give feedback.
All reactions