Skip to main content
Appentic 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.

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

​
Deploy

Open the deploy link

The README.md that feather new writes has a Deploy to Appentic link. Replace OWNER/REPO with your repository and open it:
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.

Keep the Feather setup

The new web service form recognises the app and shows Feather app, with every option on:The Release command is feather db upgrade and the Health check path is /health/ready.

Add your own variables

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.

Deploy

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

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

Appentic Feather guide

The same setup from Appentic’s side.

Production checklist

What to confirm before real users arrive.