Deploy to djustlive

djustlive is managed hosting for djust apps. The djust deploy command takes the project directory you are in, uploads it, and waits until the new version is serving.

For running djust on your own servers instead (uvicorn, a Redis state backend, a WebSocket-aware proxy) see Production Deployment.

The deploy path

The deploy CLI ships with djust itself; there is nothing extra to install.

djust deploy login      # once: opens your browser to sign in
djust deploy            # from the project directory
djust deploy status     # afterwards, or any time

djust deploy login signs you in through the browser and stores the token in ~/.djustlive/credentials. djust deploy logout removes it.

djust deploy with no arguments walks through whatever is not done yet:

1. Log in, if you have not.
2. Pick the project. The slug comes from [tool.djust.deploy].project in pyproject.toml; if there is none it asks, and offers to save your answer there so the next deploy does not ask again.
3. Create the project on djustlive if it does not exist yet, after asking.
4. Check your settings (the deploy doctor, below).
5. Upload the directory and wait for the rollout, printing its status, then Application available at: <url> when the new version is live.

To name the project explicitly, pass it: djust deploy my-app.

To deploy the latest pushed commit rather than your working tree, put the flag first: djust deploy --from-git my-app. (Written the other way round, djust deploy my-app --from-git, it fails with No such option in djust 1.2.)

djust deploy status prints the current deployment state as JSON; add a slug to see one project: djust deploy status my-app.

DJUST_SERVER overrides the server URL (default https://djustlive.com). The full command reference is djust-deploy CLI.

The deploy doctor

Before uploading, djust deploy reads your settings module and warns about settings that deploy fine but fail once running on djustlive. The warnings never stop the deploy — read them.

The platform injects SECRET_KEY, ALLOWED_HOSTS and DATABASE_URL at runtime, and the app's filesystem is read-only. The doctor flags:

• SECRET_KEY assigned a string literal instead of read from the environment.
• ALLOWED_HOSTS as a hardcoded list — the platform's hostname then gets a 400 Bad Request (DisallowedHost).
• A DATABASES block that reads nothing from the environment.
• sqlite3 as the database engine — a database file under the project directory fails on its first write, because that filesystem is read-only. Use the injected DATABASE_URL.

The project template from djust new reads ALLOWED_HOSTS from the environment already. Its database is SQLite at the path in DJUST_SQLITE_PATH, which its comments say djustlive mounts writable. The doctor warns on any sqlite3 engine, so expect that warning with the template's settings as they are.

# settings.py
import os

import dj_database_url  # or parse DATABASE_URL however you prefer

SECRET_KEY = os.environ["SECRET_KEY"]
ALLOWED_HOSTS = [
    host.strip()
    for host in os.environ.get("ALLOWED_HOSTS", "localhost,127.0.0.1").split(",")
    if host.strip()
]
DATABASES = {"default": dj_database_url.parse(os.environ["DATABASE_URL"])}

Production checklist

• Read SECRET_KEY, ALLOWED_HOSTS and the database from the environment; act on every deploy doctor warning.
• Set DEBUG = False for the deployed app.
• Serve with ASGI, so WebSocket connections reach your views (see Production Deployment for why).
• Run python manage.py check --deploy locally before deploying.
• After the rollout, run djust deploy status, open the live URL, and try the interactions that matter to your users.