I am having some problems with the hanami server command. Namely I cannot start the server in production environment.
I’ve tried:
bundle exec hanami server --host 0.0.0.0 -e production
with HANAMI_ENV set to production, still I was getting my server started in development mode.
I tried with dockerfile on local, on remote server, I tried with just the command, and still nothing.
When I enter the container and check HANAMI_ENV it returns production. Same in hanami console, the env is prod, but the server starts in dev.
Going into documentation:
If HANAMI_ENV is not set, Hanami will fallback to checking RACK_ENV. If neither variable is set, the environment defaults to :development.
My question: is this a bug? Or is the documentation wrong?
In my opinion if I set the -e production argument when starting the server, that should overwrite all, otherwise I see no point in having this argument if it is overwritten by RACK_ENV anyway, which also seems to overwrite HANAMI_ENV.
Thanks for raising this issue! It sounds like a bug, and we should fix it.
Do you have the hanami-reloader gem bundled when you’re trying to run these commands? I wonder if this is an issue of the env vars getting lost when it shells out to running bundle exec guard.
Either way, you really don’t want the reloader gem bundled when you’re trying to run a prod app. If it’s in the bundle, the first thing I’d look at it making sure it’s not there.
One way to test this theory would be to run hanami server with the --no-code-reloading flag. That bypasses the reloader.
Actually I digged around the CLI repo and immedietly found a comment that casts some doubt:
module Hanami
module CLI
module Commands
module App
# Launch Hanami web server.
#
# It's intended to be used only on development. For production, you
# should use the rack handler command directly (i.e. `bundle exec puma
# -C config/puma.rb`).
#
# The server is just a thin wrapper on top of Rack::Server. The options that it
# accepts fall into two different categories:
#
# - When not explicitly set, port and host are not passed to the rack
# server instance. This way, they can be configured through the
# configured rack handler (e.g., the puma configuration file).
#
# - All others are always given by the Hanami command.
#
# Run `bundle exec hanami server -h` to see all the supported options.
So it seems that the current code is not intended to be run in production but I am not sure what is the reasoning behind it. Also if we are to stick with this (so using the hanami server command only in dev) then we would need to adjust the documentation, cause the current one suggest that hanami server is suited for both dev and prod. Not sure how to proceed in that case, should I treat this as a bug, adjust the comment and try to make the server be able to run in production mode or should we adjust the documentation and keep relying on puma directly?
The command does not even take environment option so the current documentation is super wrong
@timriley sorry for tagging but don’t feel comfy making a decision on this on my own, and don’t want to waste time on making a PR that would be quickly rejected
This would be an inappropriate usage of RACK_ENV; see this discussion for more context. TL;DR RACK_ENV was only ever meant to define the default middleware, and it had entirely different expectations from something like HANAMI_ENV.
The framework-agnostic variable suggested there is APP_ENV.
Looking at my production deployments, I’ve done as the code comment suggested:
Okey, thank you for providing the context.
So I guess the best approach (for now) would be to update the documentation with the approach suggesting using puma more directly as the current docs are misleading and suggest using RACK_ENV which shouldn’t be used for this.
I could do that, will try to in couple of days but wondering if allowing the hanami server to also run production server would eventually be something worth considering? I don’t see a reason why such an option wouldn’t be provided? All web frameworks I know do provide a rather easy way/command to simply run the server in production env.
For what it’s worth, I wasn’t aware of the original purpose of RACK_ENV until very recently.
How we handle it in Hanami is a little different. It was there mostly as a fallback to check in case HANAMI_ENV is not present. The reason for this is that Hanami 2 evolved out of a proto-framework that itself used (mistakenly, I suppose) RACK_ENV to specify its overall app environment.
To be honest, I don’t think many people would be depending on RACK_ENV for specifying a Hanami env. I think we could remove support for it altogether, so no one gets confused.
