> ## Documentation Index
> Fetch the complete documentation index at: https://docs.featherframework.org/llms.txt
> Use this file to discover all available pages before exploring further.
# Deploying to Appentic
> Push a Feather app from GitHub and get Postgres, Redis, a worker and migrations set up in one step, with no server to look after.
[Appentic](https://appentic.com) runs on Feather and knows what a Feather app needs. When
you add a web service from a repository that depends on `feather-framework`, Appentic sets
up the database, key value store, background worker, migrations and health check in the
same step. It builds the `Dockerfile` that `feather new` generates, unchanged, so the same
app still deploys anywhere else.
You pay for the machine plus a flat monthly fee per service. See
[pricing](https://appentic.com/pricing).
## Before you start
* The app is in a GitHub repository with the generated `Dockerfile` at its root. An older
app can add it with `feather docker init`.
* You have an Appentic account with credits.
Run the checks locally first:
```bash theme={null}
feather check
feather security-check
feather env check # every key config.py reads, and which are unset
```
## Deploy
The `README.md` that `feather new` writes has a **Deploy to Appentic** link. Replace
`OWNER/REPO` with your repository and open it:
```
https://app.appentic.com/deploy?repo=https://github.com/OWNER/REPO
```
Choose a project, or create one and choose a machine for it. A shared CPU machine
with 2 vCPU and 4 GB runs a Feather app, its worker, Postgres and Redis. You can also
start from a project's **Services** page and add a web service there.
The new web service form recognises the app and shows **Feather app**, with every
option on:
| Option | What you get |
| ----------------- | --------------------------------------------------------------------------- |
| Postgres database | Created and connected, `DATABASE_URL` set |
| Key value store | Created and connected, `REDIS_URL` set |
| Background worker | `feather worker --fork` from the same image, added once the service is live |
| SECRET\_KEY | Generated for the project |
The **Release command** is `feather db upgrade` and the **Health check path** is
`/health/ready`.
On the project's **Environment** page, add anything else `feather env check` lists,
such as `GOOGLE_CLIENT_ID`, `GOOGLE_CLIENT_SECRET` or `RESEND_API_KEY`.
Click **Deploy service**. The service's **Events** page shows the database and store
being created, then the first deploy with its migrations, then the worker.
Every push to the branch then builds, runs `feather db upgrade` and moves traffic to the
new version once `/health/ready` answers. If a migration fails, the deploy stops and the
running version keeps serving.
## What Feather gets without configuration
| Variable | Set by | Used for |
| ------------------------------------- | ------------------------------------------------------- | ----------------------------------------------------- |
| `PORT` | Appentic | `feather start` binds to it |
| `WEB_CONCURRENCY` | Appentic, from the service's memory | gunicorn workers in `feather start` |
| `TRUSTED_HOSTS` | Appentic, with the service's address and custom domains | Host header checks |
| `DATABASE_URL` | the connected database | SQLAlchemy |
| `REDIS_URL` | the connected key value store | `rq` jobs and the `redis` cache, chosen automatically |
| `S3_BUCKET` and the other `S3_*` keys | a connected storage service | `s3` file storage, chosen automatically |
Feather chooses the job, cache and storage backends from `REDIS_URL` and `S3_BUCKET` when
the app doesn't set them (0.9.15 and later). Proxy headers need nothing either: Appentic
forwards through one proxy, which matches Feather's `FEATHER_PROXY_FIX_NUM=1` default.
## File uploads
A container's files are replaced on every deploy. Add a storage service to the project and
connect it to the web service and the worker: the `S3_*` variables select the `s3`
backend, and `feather.storage.get_storage()` uploads to the bucket. Apps created with
storage already install the `s3` extra. For an older app, add it to the
`feather-framework[...]` line in `requirements.txt`.
## Scheduled tasks
Add a cron job that runs one of your `@job` functions once:
```bash theme={null}
feather jobs run send_digest
```
`feather jobs run` exits with a non-zero code when the job raises, so a failed run shows as
failed in Appentic.
## Your own domain
In the web service's **Settings**, add the domain and create the DNS records it shows.
Once the certificate is issued, Appentic adds the domain to `TRUSTED_HOSTS` and restarts
the service. For Google sign-in, add `https://your-domain/auth/google/callback` to the
OAuth client.
## Backups
Appentic backs up every database: continuously, plus a full backup each day, kept for 7
days. From the database's **Backups** tab you can restore to a new database at any point in
that window.
## Without the setup
Everything above is an ordinary Appentic resource, so you can also set the app up by hand:
a web service with the release command and health check path in **Settings**, a worker
running `feather worker --fork` from the web service's image, and a database and key value
store connected to both.
The same setup from Appentic's side.
What to confirm before real users arrive.