> ## Documentation Index
> Fetch the complete documentation index at: https://vytral-mintlify-6f4e9542.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Managed cloud deployments

> Deploy Harly on Render, DigitalOcean, Railway, or Fly.io with durable storage and a scheduler.

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

| Platform     | Best for                                               | Database           | Upload storage       | Deployment path                     |
| ------------ | ------------------------------------------------------ | ------------------ | -------------------- | ----------------------------------- |
| Render       | Blueprint-based setup                                  | Managed PostgreSQL | S3-compatible bucket | Deploy from `render.yaml`           |
| DigitalOcean | App Platform and managed infrastructure                | Managed PostgreSQL | S3-compatible bucket | Deploy from `.do/app.yaml`          |
| Railway      | Config-as-code for one service; CLI for the full stack | Railway PostgreSQL | S3-compatible bucket | `railway.toml` or `npx @harly/cli`  |
| Fly.io       | Teams comfortable with Fly processes                   | Managed PostgreSQL | S3-compatible bucket | `npx @harly/cli`, then `fly deploy` |

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

## 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:

```bash theme={null}
doctl apps create --spec .do/app.yaml
doctl apps update APP_ID --spec .do/app.yaml
```

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:

```bash theme={null}
npx @harly/cli deploy railway --non-interactive
```

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:

```bash theme={null}
npx @harly/cli
```

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

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

See [configuration](/deployment/configuration) and [backups](/operations/backups)
before inviting a production team.