Keep the Python build you already use
Install from requirements.txt, Pipenv, or the dependency workflow already committed to the project. Keep framework settings and migrations reviewable with the release.
Run a Python web app or worker with the dependency file, process command, health route, and secret-backed configuration kept beside the source.
Candidate release
Python
SOURCE
Git
REGION
de
ROUTE
HTTPS
01Source received
02Build completed
03Runtime started
04Health check passed
Promoted route
production.adios.run
A production path for
The production path
The application or service is only one part of production. Build evidence, runtime state, health, secrets, logs, routes, and the promoted version should remain inspectable together.
Install from requirements.txt, Pipenv, or the dependency workflow already committed to the project. Keep framework settings and migrations reviewable with the release.
Use Gunicorn, Uvicorn, or another production process that binds to the declared port. A candidate becomes current only after the configured health route responds.
Build output, runtime logs, health state, secrets, domains, and the promoted release stay attached to the project instead of being split across unrelated tools.
From source to release
Use the source and production behavior the project already has. The manifest records what the platform should build or provision and how the result becomes ready.
Bring the existing repository, or inspect and deploy one of the exact starter variants linked below.
$adios loginKeep commands, runtime or service version, health behavior, and secret references in adios.yaml.
$git diff -- adios.yamlFollow build and runtime evidence, verify the candidate, and open the promoted route or service connection.
$adios upname: python-api
build_cmd: pip install -r requirements.txt
start_cmd: gunicorn app:app --bind 0.0.0.0:8000
runtime:
name: python@3.13
port: 8000
health_path: /healthzDeployable starting points
Compare FastAPI, Django, and Flask starters before choosing the framework and package workflow for the first release.
API starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-fastapi.git
cd template-python-fastapi
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-fastapi-pipenv.git
cd template-python-fastapi-pipenv
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-django.git
cd template-python-django
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-django-pipenv.git
cd template-python-django-pipenv
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-flask.git
cd template-python-flask
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/template-python-flask-pipenv.git
cd template-python-flask-pipenv
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/templates.git
cd templates/python/litestar
adios upAPI starters
FastAPI, Django, Flask, Litestar, and Sanic starters with production start commands.
git clone https://github.com/adiosdotdev/templates.git
cd templates/python/sanic
adios upBefore production
The safest first release starts with a reproducible build or service configuration and a preview that exercises the dependencies production will actually use.
Questions, answered
Review the runtime or service boundary, template path, failure behavior, and production checks before creating the first release.
Yes. Run the Adios CLI from the project root, keep the repository and dependency files you already use, and add an adios.yaml file that describes the production build, start command, port, and health path.
Not for a standard supported runtime. Use the project's normal production commands in adios.yaml. If the build needs unusual operating-system packages or native libraries, verify those dependencies in a preview before promotion.
The example runtime uses Python 3.13, and the template catalog includes pip and Pipenv variants. Match the runtime and install command to the versions supported by your application.
Yes. Provide a persistent worker start command, inject broker or database credentials as secrets, and verify retry, shutdown, and dependency-failure behavior before promotion.
The candidate release keeps its build and runtime output for inspection. It must report healthy before it becomes the promoted version serving the application route.
Yes. This page links to the closest official Adios Python starters. Inspect the exact source variant, deploy it in the console, or clone it locally and run adios up.
Related deployment paths
Deploy a FastAPI service with its ASGI import target, dependency install, runtime port, health endpoint, secrets, and promoted release tied to source.
Ship a Django project with a production WSGI process, runtime settings, database credentials, health checks, static asset decisions, and release evidence in one place.
Take a Flask application from a local development server to a persistent Gunicorn process with a documented port, health check, logs, and production route.
Choose a PostgreSQL version, keep database credentials out of Git, attach persistent storage, connect the application, and verify data after a restart.
The first release
Start from the repository or a template, review the deployment contract, and inspect what becomes the promoted production version.