Features
Everything your Django app needs, done properly.
Easy to start, safe to run and built on AWS. Here is what is included, in plain words, with a link to the docs for each. To see what happens during a deploy, read How it works.
Get it live
From your machine or your repository onto AWS, the same way every time.
Deploy with one command
Run djangocloud deploy in your project and watch the build and release in your terminal. Nothing is created until you confirm. Your .env file, git history and virtualenv are never uploaded. Docs →
Every push to GitHub goes live
Connect a repository and a branch, and each push to that branch is released for you. The GitHub App only reads the repositories you pick, and a build gets short-lived access to the one repository being built. Docs →
Automate it from CI or an AI coding tool
An API token runs the same deploy, rollback and scale commands from your pipeline, or from an AI coding tool that can run commands. Docs →
It works with the project you already have
Bring your requirements.txt, or pyproject.toml and uv.lock, as they are. We find your app on our own, and you can change the build settings if your project is set up differently. Docs →
Django, taken care of
The things that usually decide whether a first deploy works.
Settings and secrets you can change safely
Paste your settings in the dashboard or run djangocloud env push. They are stored encrypted and never shown again. A change applies to the next release, and a rollback brings back the settings that release had. Docs →
Your database is updated before each release goes live
Migrations run automatically before the new version starts. If the new version cannot start or pass its health check, the previous release keeps serving your visitors. Docs →
Your site comes up with its styles
Your static files (CSS, JavaScript and images) are collected during the build and served for you, so a deploy does not come up unstyled. Docs →
Postgres, connected for you
Add a managed Postgres database from the dashboard and your app is connected to it. You can also use any Postgres your app can reach. SQLite is not suitable in production because the app's disk is reset on every deploy. Docs →
Background tasks with Celery, set up for you
Add a task queue (Amazon SQS) and turn on a worker from the dashboard. The worker runs next to your app as a second container from the same image, and the queue's login is added to your deployment. You paste one snippet into settings.py and, if you have no Celery app yet, create celery.py. Celery itself is installed for you. The queue page shows what is waiting, how fast tasks are finished and what failed. Docs →
Uploads that survive every deploy
Add file storage, a private S3-compatible bucket, from the dashboard and paste one snippet into settings.py. Files stay when you redeploy. Pick 5, 100 or 250 GB; the page shows how full it is and when it will run out. Docs →
Your own domain, with HTTPS
Your app has a secure https:// address from its first release. For your own domain, we set up DNS and the certificate in your AWS environment, and you change the nameservers at your registrar (or add NS records for a subdomain). Up to 5 domains per deployment. Docs →
No ALLOWED_HOSTS or CSRF_TRUSTED_ORIGINS to edit
Your app is set up to accept requests on its own address, and on your custom domain once it is live, so you never have to touch these settings. Docs →
Keep it running
What keeps your app healthy once real users arrive: seeing what is happening, undoing a mistake and adding capacity.
Undo a bad release in one click
Every deploy is saved as a numbered release. Roll back to one of the newest three in the dashboard or with djangocloud rollback. Your code rolls back, database changes do not, so you get a warning when an older release would run against a newer database. Docs →
Find problems fast with searchable logs
App, build and release logs in the dashboard, with search, time ranges and levels, or in your terminal with djangocloud logs. Logs are kept for 30 days, up to 20,000 lines per project. Docs →
Charts and alerts, without opening the AWS console
CPU and memory charts are updated every 5 minutes and kept for 30 days. Alerts tell you when CPU or memory spike. Docs →
Add capacity when traffic grows
Pick a server size from Nano to XLarge and run 1 to 20 instances per app, from the dashboard or with djangocloud scale. Autoscaling can add instances when traffic spikes. Docs →
Run several projects from one account
Run and manage more than one app from a single account. Docs →
Good to know first
The things that surprise people most. The full list is in the known limitations.
- Files written to disk are lost on every restart and deploy. Use Postgres and file storage (a private bucket you add from the dashboard).
- A rollback restores code and environment variables, not the database.
- Sources are limited to 100 MB, a build that runs for around 9 to 10 minutes is stopped, and Python 3.10 to 3.13 are supported.
- Each deployment runs in one AWS region, which you choose when you connect, and stays there.
- Apps run in Lightsail container services. Custom networking, GPUs and multi-region failover are not offered.
- Websockets work when you run an ASGI application. Celery workers run as a second container next to your app, sharing its CPU and memory and running once per instance. Scheduled jobs (Celery beat, cron) are not available.
- Always on: an app keeps running, and being billed, around the clock. There is no scale-to-zero.
Deploy your first Django app.
See what it costs, or go straight to your first deploy.