Hanami
What Gigadrive Network detects for a Hanami application and the defaults it runs with.
Gigadrive Network detects Hanami when your Gemfile.lock lists the hanami gem and a config.ru file exists. That config.ru becomes the Function that answers every path.
Defaults
| Setting | Value |
|---|---|
| Runtime | The Ruby version your project names, ruby-34 when it names none |
| Memory | 256 MB |
| Max duration | 30 seconds |
| Entrypoint | config.ru |
| Route | /* to the entrypoint |
| Assets | public, when the directory exists |
| Excluded | tmp/, log/, spec/, node_modules/ |
The preset writes HANAMI_ENV=production and RACK_ENV=production. tmp and log are created empty and writable; what a Function writes there stays with that copy of the Function.
A new Hanami application keeps its database in SQLite and sets DATABASE_URL only for development, in .env, which Hanami does not read in production. When your lockfile lists hanami-db and sqlite3 and you store no DATABASE_URL, each copy of your Function starts with its own SQLite database in tmp/, with your migrations already run: the build runs them once. That data belongs to one copy and is gone when it stops, so store a DATABASE_URL for a PostgreSQL or MySQL server under Environment variables for anything you keep, and run hanami db migrate against it yourself.
The build
The build installs your gems with Bundler into vendor/bundle, leaving out the development and test groups. When your lockfile lists hanami-assets, it then runs hanami assets compile, and the compiled files in public/assets are published to the edge. Hanami's asset compilation runs on Node.js, which the build provides.
Your application runs on Puma and receives every request unchanged, as described for Ruby Functions.
Hanami's own guides live at guides.hanamirb.org.