Anvil Runtime: a Python-only web app framework with a standalone server

What the runtime actually is

Anvil is a framework for building full-stack web apps with nothing but Python. Your browser-side code is in Python, your user interface is in Python, your server-side code is in Python, and your database is all Python objects. The Anvil Runtime is the open-source engine that powers those apps, and this repository contains the Anvil Runtime libraries as well as a standalone App Server which uses the Runtime to serve an Anvil app from the local filesystem. The primary language is recorded as TypeScript, which is a detail about how the engine itself is implemented rather than about the language you write in. The licence is one GitHub cannot classify, the homepage is anvil.works/open-source, the last push was on 2026-09-24, and the repository has no GitHub releases, so the version marker lives in the packaging metadata.

The cloud editor is optional, and the README says so

The easiest way to build an Anvil app is the free online editor at anvil.works, which includes a drag-and-drop GUI builder and free built-in hosting for your apps. But the README is explicit that you do not need the cloud service at all to build or run Anvil applications. That sentence matters for how you should read the project. The cloud editor is the pleasant path and the one most people will use, but the runtime and the standalone server are the actual product, and they are usable on their own. The repository root shows the shape of that, with `client/` for the browser-side runtime, `server/` for the server side, `database/` for the data layer, `uplink/` and `downlink/` for the two directions of the app's connectivity, `services/` for the built-in service integrations, `html-form-parser/`, `packaging/`, `doc/`, `tests/` and a `LICENSE`.

Running the standalone App Server

The standalone web server serves a single Anvil app, and launching it is three commands:

$ pip install anvil-app-server
$ create-anvil-app todo-list MyTodoList
$ anvil-app-server --app MyTodoList

The middle command scaffolds a new app from a template, and the last one points the server at it. The documentation points at a getting started guide in `doc/getting-started.md` for a step-by-step walkthrough, and a separate guide at `doc/creating-and-editing-apps.md` for creating and editing an Anvil app using a text editor rather than the browser-based IDE. That second guide is the one to read if you intend to keep your app in version control with your own tooling.

No configuration required, and what that hides

The feature list makes the pitch plainly. The Anvil App Server includes its own database, Postgres, and reverse proxy, Traefik, so all you need to do is launch it, with no need to spend half an hour setting up your environment. The same list covers full-stack apps with nothing but Python, with the app server running your client-side code in the web browser and the server-side code in server-side Python, and it even has a built-in database with rows that can be passed freely between server and client code. HTTPS comes out of the box too, because if launched with an HTTPS origin the app server will launch an HTTPS reverse proxy and obtain a certificate from Let's Encrypt. The honest reading is that the convenience is real but it is also a substantial amount of machinery started on your behalf, which matters when you later want to know what is listening on which port.

Uplink, downlink and the interactive shell

The distinctive feature is connectivity from outside the app. The Anvil Uplink allows you to connect scripts, Jupyter notebooks, or anything else with a Python interpreter to your app, and there is an interactive shell for it, since you can launch the server with `--shell` to connect a fresh Python interpreter via the Uplink. The security model behind that is visible in the option list, which has separate keys for privileged and unprivileged connections: `--uplink-key` is the key to connect server, privileged, uplinks to this app, and `--client-uplink-key` is the key to connect client, unprivileged, uplinks. There is also `--downlink-key`, the authentication key for a separately launched downlink, and `--dep-id ID=PACKAGE` to associate a dependency app ID with its package name. So a Jupyter notebook can be inside the trust boundary of an app, and the keys are what draw that boundary.

The option list, and the deployment knobs

The advanced configuration options are a long flat list, and the interesting ones cluster around running behind a proxy. There is `--origin URL` to set the home URL of the app, `--disable-tls` to not terminate TLS connections regardless of the origin scheme, and `--forward-headers-insecure` which, when running embedded TLS termination, passes through the X-Forwarded-* headers and is off by default. The default off is a deliberate security choice, since trusting forwarded headers from an unverified source lets a client claim any host. There is `--add-hsts-headers` to enable HSTS headers when the origin URL uses https (off by default), and `--letsencrypt-storage PATH` for the certificate JSON file, with `--letsencrypt-staging` to use the staging server and `--manual-cert-file` and `--manual-cert-key-file` for your own PEM certificate. For data there is `--database DB-URL`, `--data-dir DIRECTORY` defaulting to `.anvil-data`, `--auto-migrate` to migrate data table schemas automatically and `--ignore-invalid-schema` to run anyway.

Email, authentication and the rest

The remaining options cover the two integrations an application always ends up needing. For email there is `--smtp-server-port` to accept SMTP email on a specified port, which is what makes the app's own address work, plus `--smtp-host`, `--smtp-port`, `--smtp-encryption` to use TLS, `--smtp-username` and `--smtp-password`. For sign-in there is a full set of social providers, with `--google-client-id` and `--google-client-secret` plus `--google-api-key` and `--google-refresh-token` for delegated Google access such as App Files, `--facebook-app-id` and `--facebook-app-secret`, and `--microsoft-app-id`, `--microsoft-app-secret` and `--microsoft-tenant-id` for Microsoft accounts. There is also `--secret NAME=VALUE` to provide an app secret and `--encryption-key NAME=VALUE` to pass an app encryption key, and network options with `--ip`, `--port` and `--http-redirect-port` to redirect plain HTTP to HTTPS. A config file can also be loaded from YAML with `--config-file FILENAME`.

Editorial conclusion

Adopt the Anvil Runtime if you want to build a full-stack web application where the browser code, the UI, the server code and the data model are all Python, and you would rather not assemble the infrastructure yourself. Skip it if your team already has a frontend framework and a deployment pipeline, since Anvil replaces those decisions rather than fitting into them. Before you start, note that the standalone server bundles Postgres and Traefik and can obtain a Let's Encrypt certificate, so the footprint is larger than a single Python process.

Frequently asked questions

Official sources

1. anvil-works/anvil-runtime on GitHub
2. Issues
3. Project website
4. README