M Mermaduckle Deployment guide
Production deployment guide

Use the public demo here. Run production in your own environment.

This domain hosts the marketing site, a public sample-data demo at /demo, a limited hosted beta at /app, and this deployment guide. The same Rust service can also run as a separate customer-owned deployment on Fly, Railway, or your own infrastructure with Postgres as the production data layer.

01

Deployment model

Mermaduckle supports three operating modes: a public demo for evaluation, a hosted beta for invited users, and a private deployment model for teams that want customer-owned production environments.

Public demo

Evaluate the UI with sample data.

Review workflows, approvals, audit trails, and settings without using production credentials.

Hosted beta

Use the managed app selectively.

The hosted beta at /app is where invited testers use the real product while rollout stays controlled.

Private deployment

Run production under your ownership.

Deploy the same Rust service on Fly, Railway, or your own stack, with Postgres as the production target.

02

Local start

Run a local instance from the repository root and inspect every route served by the app.

cargo run -p mermaduckle-server
  • / marketing site
  • /demo public demo UI
  • /app hosted beta UI
  • /docs deployment guide
  • /api/health service readiness endpoint

Local start lets you inspect the marketing site, demo, hosted beta shell, and API in one process. Production deployments should run with DATABASE_URL pointing at Postgres.

03

Deploy to Fly.io

Use Fly for the app tier today. The repository already includes the Dockerfile and fly.toml required for a Fly rollout, with Postgres as the production target architecture.

flyctl deploy -a <app-name> --remote-only --config fly.toml

The current repo is configured around a single Rust service that serves the marketing site, public demo, hosted beta, docs, and API from internal port 3001. Neon is the recommended default when you want one Postgres database that works cleanly with both Fly and Railway.

04

GitHub Actions deploys

Push to main to trigger Fly deployment after CI passes.

fly tokens create deploy --app <app-name>
  • Add the token as the repository secret FLY_API_TOKEN.
  • Store DATABASE_URL as a deployment secret so the server can connect to Postgres at startup.
  • The deployment workflow lives in .github/workflows/fly-deploy.yml.
  • The workflow runs flyctl deploy --remote-only --config fly.toml.
05

Domains and TLS

Use these Fly commands when mapping a production domain and issuing certificates.

flyctl domains add mermaduckle.com -a <app-name>
flyctl ips allocate-v4 -a <app-name>
flyctl certs create mermaduckle.com -a <app-name>
06

Environment variables

These runtime values are read by the server when the deployment starts.

DATABASE_URLpostgresql://<user>:<password>@<host>/<db>?sslmode=require required Postgres connection
OLLAMA_URLhttp://localhost:11434 model runtime endpoint
HOST0.0.0.0
PORT3001

The current server startup path requires DATABASE_URL. Use a Postgres connection string from Neon or your platform provider so the app tier stays portable and the data tier stays shared.

07

Deployment artifacts in the repository

These files are the key parts of the current Fly deployment and release workflow.

  • deploy/Dockerfile.fly
  • fly.toml
  • .github/workflows/fly-deploy.yml
  • tools/deploy_fly.ps1
  • crates/server/static/demo/
  • crates/server/static/app/
  • docs/deploy/fly.md
  • README.md