FAQ

Hosting for Rails apps. You run hadoken in your project directory and get a live HTTPS URL. No config files, no Dockerfile, no infrastructure to manage.

No. Hadoken reads your Gemfile.lock and builds a container automatically using Cloud Native Buildpacks. No Dockerfile, no Procfile, no YAML.

It deploys. hadoken is an alias for hadoken deploy. On first run it detects your app, creates a project, builds, deploys, and prints the URL. After that, it just deploys.

Files tracked by git (git ls-files). Your .gitignore is respected. Use --include-untracked to add untracked files.

Yes. Each app gets a persistent volume. SQLite databases survive across deploys.

Hadoken detects your database from the gems in your Gemfile.lock (pg or mysql2). You'll need to set DATABASE_URL via hadoken env set to point at your database host.

Yes. rails db:prepare runs on every deploy. For manual migrations, use hadoken run -- rails db:migrate.

hadoken env set KEY=VALUE. Each change triggers a rolling restart. Values are encrypted at rest and masked in output by default.

No. It's a standalone Go binary. No Ruby dependency. It talks to the Hadoken API over HTTPS.

Hadoken replaces Kamal, it doesn't wrap it. There's no config/deploy.yml. Hadoken handles the full pipeline: build, deploy, TLS, env vars, logs, console. You don't manage servers.

Similar developer experience, but Hadoken is built specifically for Rails. It detects your stack from Gemfile.lock, runs migrations automatically, and gives you Rails console access out of the box.