mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-08-28 05:27:41 +00:00
914778c8a8
Remove server-side TLS listener support so Fabro only binds plain TCP or Unix sockets, and update docs/tests around proxy-terminated HTTPS. This also drops the removed [server.listen.tls] config shape and the inbound TLS-specific diagnostics, fixtures, and integration coverage.
89 lines
4.9 KiB
Text
89 lines
4.9 KiB
Text
---
|
|
title: "Render"
|
|
description: "Deploy Fabro to Render via the render.yaml blueprint, with a persistent disk for state"
|
|
---
|
|
|
|
<Warning>
|
|
The server interface is in private early access. Contact [bryan@qlty.sh](mailto:bryan@qlty.sh) if you're interested in trying it.
|
|
</Warning>
|
|
|
|
[Render](https://render.com) can host the Fabro server by pulling the pre-built image published to GHCR. The repo ships a `render.yaml` blueprint that provisions the service and a persistent disk for `/storage` in one click, so your runs, checkpoints, and sessions survive redeploys.
|
|
|
|
## One-click deploy
|
|
|
|
[](https://render.com/deploy?repo=https://github.com/fabro-sh/fabro)
|
|
|
|
The button opens Render's blueprint flow pointed at this repo. `render.yaml` instructs Render to build `Dockerfile.deploy`, which is a thin wrapper that pulls `ghcr.io/fabro-sh/fabro:nightly` — no Rust compilation on Render's builder, so deploys complete in seconds.
|
|
|
|
The blueprint declares:
|
|
|
|
- A `web` service (Docker runtime) on Render's `starter` plan
|
|
- A 1 GB persistent disk mounted at `/storage`
|
|
- A health check on `/health`
|
|
|
|
## First-deploy checklist
|
|
|
|
The blueprint covers the infrastructure; a few pieces still need to be wired up after the first deploy.
|
|
|
|
### 1. Confirm the disk is attached
|
|
|
|
Fabro writes all persistent state — run history, checkpoints, sessions, the default token, and JWT keys — under `/storage`. The blueprint provisions a 1 GB disk at that path automatically. Verify in **Service → Disks** that `fabro-storage` is present and mounted at `/storage`. Grow the size later from the same page if needed.
|
|
|
|
<Note>
|
|
Render persistent disks require a paid plan (`starter` or higher). The free tier does not support disks, so the blueprint selects `starter` by default.
|
|
</Note>
|
|
|
|
### 2. Confirm the target port
|
|
|
|
Render sets `$PORT` automatically and expects the container to bind to it. The Fabro image honors `$PORT` and falls back to `32276`, so Render's default HTTP routing works without any manual port configuration.
|
|
|
|
### 3. Set required environment variables
|
|
|
|
Add variables in **Service → Environment** as needed. The [Server Configuration](/administration/server-configuration) reference has the full list; the minimum useful set:
|
|
|
|
| Variable | Purpose |
|
|
|---|---|
|
|
| `ANTHROPIC_API_KEY` / `OPENAI_API_KEY` / `GEMINI_API_KEY` / ... | At least one LLM provider key for the models you'll run |
|
|
| `FABRO_DEV_TOKEN` | Optional — pre-set the dev token instead of reading the one written to `/storage` on first boot |
|
|
| `SESSION_SECRET` | 64-character hex string; required when the web UI is enabled |
|
|
| `GITHUB_APP_CLIENT_SECRET`, `GITHUB_APP_WEBHOOK_SECRET`, `GITHUB_APP_PRIVATE_KEY` | Only if you enable GitHub OAuth or the GitHub App integration |
|
|
|
|
No `.env` file is auto-loaded inside the container; everything comes from Render's environment.
|
|
|
|
## Accessing your Fabro server
|
|
|
|
Once the deploy is healthy, Render exposes a `*.onrender.com` URL (or your custom domain). Two things to grab:
|
|
|
|
1. **The dev token** — on first boot, Fabro writes one to `/var/fabro/dev-token` and logs it. Find it in **Service → Logs** in the Render dashboard, or open **Service → Shell** and run `cat /var/fabro/dev-token`.
|
|
2. **Point your local CLI at the server** — add the Render URL to `~/.fabro/settings.toml`:
|
|
|
|
```toml title="~/.fabro/settings.toml"
|
|
[cli.target]
|
|
type = "http"
|
|
url = "https://<your-service>.onrender.com/api/v1"
|
|
```
|
|
|
|
Then commands like `fabro model list --server <url>` will hit your Render instance.
|
|
|
|
See [Running the Fabro Server](/administration/deploy-server) for the full auth and CLI-pointing story.
|
|
|
|
## Redeploys and updates
|
|
|
|
Render re-pulls the GHCR image on every deploy. `Dockerfile.deploy` references the `:nightly` tag by default, so redeploying picks up the latest nightly automatically. To pin a specific version, edit `Dockerfile.deploy` to reference `ghcr.io/fabro-sh/fabro:<version>` and redeploy. The `/storage` disk survives redeploys, so runs and checkpoints persist.
|
|
|
|
## Caveats
|
|
|
|
- **Disk is load-bearing.** `/storage` holds the dev token and JWT signing keys in addition to runs and checkpoints. Do not detach or resize it destructively once the service is in use.
|
|
- **Single replica.** Fabro's server currently assumes one process owns `/storage`. Don't scale the service to multiple instances.
|
|
- **Architecture.** Render runs x86_64 (amd64) containers. The `:nightly` tag is multi-arch, but the arm64 variant is not currently usable — stay on amd64, which is Render's default.
|
|
|
|
## Next steps
|
|
|
|
<Columns cols={2}>
|
|
<Card title="Running the Fabro Server" icon="server" href="/administration/deploy-server">
|
|
Auth, dev tokens, submitting runs, and pointing the CLI at your deployment.
|
|
</Card>
|
|
<Card title="Server Configuration" icon="gear" href="/administration/server-configuration">
|
|
Full `settings.toml` reference — reverse-proxy TLS, auth methods, concurrency, and more.
|
|
</Card>
|
|
</Columns>
|