Feather

Feather is the Python framework Appentic itself is built on. When you create a web service from a Feather app's repository, Appentic recognises it and offers to set up everything the app needs in the same step.

What Appentic recognises

A repository is a Feather app when its requirements.txt or pyproject.toml depends on feather-framework.

Set up a Feather app

1. Commit your migrations. The release command (feather db upgrade) applies them, and nothing else creates your tables. On Feather 0.9.18 or later, a missing migration stops the deploy instead of starting against an empty database.

2. Create a project and choose a machine.

3. On the project's Services page, click Add next to Web Services and choose the repository.

4. The form shows a Feather app section with these options, all on by default:

   Option	What Appentic does
   Postgres database	Creates a database, connects it and sets DATABASE_URL.
   Key value store	Creates a store for background jobs and the cache, connects it and sets REDIS_URL. Also sets JOB_BACKEND=rq and CACHE_BACKEND=redis for the project, unless they're already set.
   Background worker	Adds a worker that runs feather worker --fork from the web service's image, connected to the same database and store.
   SECRET_KEY	Generates a random SECRET_KEY for the project, unless it already has one.
   Production mode	Always on. Sets FLASK_CONFIG=production for the project, so debug is off and cookies are secure, unless FLASK_CONFIG or FLASK_ENV is already set.

   The section also fills in the Release command (feather db upgrade) and Health check path (/health/ready). See Release commands and health checks.

5. Add any other variables your app reads, such as GOOGLE_CLIENT_ID or RESEND_API_KEY, on the project's Environment page. Run feather env check locally to list them.

6. Click Deploy service.

Before creating anything, Appentic checks that everything fits on the web service's machine and that your balance covers it.

Your Dockerfile

Appentic builds your app with its own Dockerfile when the repository has one, like the one feather new writes. That one works as it is: it starts the app with feather start, which listens on the port Appentic sets in PORT.

Without a Dockerfile, Appentic builds the app the way Feather does: it builds your assets with Vite and Tailwind, then runs feather start in production mode. That needs the layout feather new creates: a requirements.txt that names feather-framework, package.json, vite.config.js, static/ and templates/. Without it, the build and start commands on the form are used.

If your Dockerfile starts the app on a fixed port instead, such as --bind 0.0.0.0:10000, the app never receives traffic. The form says so before you deploy. Change the start command to listen on PORT, for example --bind 0.0.0.0:${PORT} in the shell form of CMD.

Sizes

Everything the setup creates runs on the same machine as the web service and is sized to fit beside it. Appentic picks the largest of these that fits:

The database, store and worker are named after the web service, for example shop-db, shop-redis and shop-worker. They're ordinary resources, so you can resize or remove any of them later. The service's Events page lists the sizes chosen.

What happens next

The service's Events page follows the setup:

1. The database and key value store are created. This takes a minute or two.
2. Once both are connected, the first deploy starts. The release command runs your migrations against the new database.
3. Once the service is live, the worker is created from the same image and connected.

If the database or store can't be created, the setup stops and the Events page says why. Fix or remove it, then deploy. If the first deploy fails, the worker is added once a later deploy goes live.

What else Appentic sets

Feather reads these with no configuration:

To add file storage, create a storage service and connect it to the web service and the worker. Feather 0.9.15 or later uses it with no configuration.

Scheduled tasks

A cron job can run any Feather background job once on a schedule:

feather jobs run send_digest

Sign-in emails

A Feather app can sign people in with a code sent by email instead of with Google. Set SIGN_IN_METHOD = "email" (or create the app with feather new --sign-in email). This needs Feather 0.9.32 or later. You don't need a Google Cloud project, and on Appentic you don't need an email provider either, because Appentic sends the sign-in emails.

Every project gets SIGN_IN_RELAY_URL and SIGN_IN_RELAY_TOKEN when its first web service is created. Feather uses them to send sign-in codes through Appentic.

• The email comes from signin@appentic.com, shows your app's name as the sender, and says it was sent from Appentic for your app.
• It contains a six-digit code and no links. The code works once, only in the browser that asked for it, and expires after 15 minutes.
• Each project can send 60 sign-in emails an hour, and each address can receive 5 an hour.

The relay only sends sign-in codes. For any other email your app sends, set RESEND_API_KEY and RESEND_FROM_EMAIL from your own Resend account on the Environment page. To send sign-in codes from your own domain as well, delete SIGN_IN_RELAY_URL. Feather uses the relay whenever it's set.

With a coding agent

A coding agent connected to Appentic can set up the same stack for a Feather app, always with a database, and with a key value store, worker and storage when you ask for them. See What an agent can do.