Skip to main content
Harly needs a persistent web process, PostgreSQL, durable file storage, and a separate scheduler worker. Vercel-only deployments are not supported because serverless functions cannot provide the scheduler lifecycle Harly requires.

​
Choose a platform

App Platform filesystems are ephemeral. Use S3, R2, or another S3-compatible provider before accepting candidate resumes or attachments.

​
Render

  1. Open the Render deploy link from the Harly repository.
  2. Create independent values for the runtime secrets.
  3. Paste the same shared runtime secrets into both the web and scheduler services when Render asks for them.
  4. Confirm the database is production-grade and the image tag is pinned.
  5. Open https://<your-app>.onrender.com/setup and claim the owner with the HARLY_SETUP_SECRET you saved before deployment.

​
DigitalOcean App Platform

Use .do/app.yaml as the canonical App Platform spec. It describes the web service, scheduler worker, pre-deploy migration job, managed PostgreSQL, health check, and runtime variables in one file. The repository’s Deploy to DigitalOcean button reads this file automatically. With doctl, the same spec can be created or updated explicitly:
For production, replace the development database entry with a managed PostgreSQL cluster and keep the runtime on linux/amd64. Configure S3 before the first upload. The migrate job must finish before the web and scheduler services receive traffic.

​
Railway

Railway automatically reads railway.toml (or railway.json) from the source repository and applies its build/deploy settings to the current service deployment. Harly’s file selects the root Dockerfile, starts the web role, and uses /api/health/ready for readiness. Railway config-as-code is intentionally service-scoped; it does not create the database, scheduler, or migration service. Use the CLI for a complete project:
Railway Templates are the native multi-service equivalent, but publishing one is a Railway-account operation. Once Harly has an official template, the template can be deployed with Railway’s template workflow; until then the CLI API path is the reproducible full-stack path.

​
Fly.io

Run the CLI from a secure workstation:
For Fly.io, the CLI prepares fly.toml; run fly deploy after attaching a database and setting secrets. For Railway, the CLI creates separate web, scheduler, and migration roles through the API. Secrets are never written to a local file unless --save-env is explicitly supplied; that opt-in file is written with mode 0600 and a warning. Complete /setup only after readiness is green.

​
Production checklist

Web and scheduler run as separate long-lived processes.
PostgreSQL backups and point-in-time recovery are enabled.
S3 bucket encryption and versioning are enabled.
Secrets are stored in the platform secret manager.
Readiness and scheduler health are monitored.
A restore drill has completed against a throwaway installation.
See configuration and backups before inviting a production team.