How it works

Easy to deploy. Safe to run.

We build your Django project and run it on AWS, so you do not have to. A few commands put it live, and a release that fails never replaces the one that works.

A few commands. No changes to your project.

Install the CLI, sign in, send your settings and deploy. Nothing needs adding to your Django settings.

# install the CLI and sign in (you approve a code in the browser)
$ pip install djangocloud-cli
$ djangocloud login

# send your settings and secrets (your .env file is never uploaded as a file)
$ djangocloud env push .env

# build, migrate, release
$ djangocloud deploy

# afterwards
$ djangocloud status
$ djangocloud logs -f

Using uv? uv add djangocloud-cli. Prefer manage.py? Add "djangocloud_cli" to INSTALLED_APPS and run python manage.py djangocloud deploy. Or connect GitHub and every push to your branch deploys. All CLI commands →

What happens when you deploy

A deploy from the CLI and a push to GitHub go through the same six steps, and the CLI shows the build and release as they happen.

  1. 1. Your code arrives

    From an upload by the CLI, or from GitHub with read-only access that expires quickly.

  2. 2. A release is saved

    Every deploy is saved with its build settings and environment variables, so you can go back to it exactly as it was.

  3. 3. Your app is built

    We build it in a clean, throwaway AWS CodeBuild container. It receives your source code and a temporary push-only login to store the result, and nothing else.

  4. 4. The new version starts

    The new version is deployed to your Lightsail container service. Your release command, by default migrate --noinput, runs first, so your database is ready before the server starts.

  5. 5. We check that it works

    We wait until your app answers on its health check path, and only then mark the release active and the previous one superseded.

  6. 6. It goes live

    Your app is served over HTTPS. If any step fails, the release is marked failed and the previous release keeps serving.

More detail: how your app is run, build settings, failed deploys.

Your app runs on AWS, kept apart from everyone else's

Every app gets an AWS account of its own, which keeps it separate from other customers. Which account that is depends on the plan. Under the hood your app runs on Amazon Lightsail container services: one or more identical copies of a size you choose, behind an HTTPS address.

Fully managed: nothing to connect, no AWS bill

  • We create a dedicated AWS account for you and run your app there. There is nothing to connect and no AWS bill.
  • Other customers are separated from you by the account boundary. We have full access to the account we run.

Self-hosted: your own AWS account, your own bill

  • Your app, your database and your AWS bill stay in your own account, and AWS bills you directly for servers and databases.
  • You give us access through a role that you create from one ready-made template. We never ask for your AWS password, and deleting the role ends our access at once.
  • The role is limited to what we need: Lightsail and our own build resources. It gives us no access to your other AWS services. While it is connected, we can act in your account within that policy, and everything we do is recorded in your own CloudTrail log.
  • Is my AWS account safe? (plain language) · The security model, including its limits →
How the access works, in detail
  • You create a cross-account IAM role in your account from one CloudFormation stack (AWS opens with everything filled in). Its trust policy names Django Cloud and requires your personal ExternalId, the standard guard against the confused deputy problem. Django Cloud connects by itself when the stack finishes.
  • Django Cloud uses sts:AssumeRole and gets short-lived credentials that expire within an hour. No long-lived key of yours is stored. An IAM user's access key still works as a fallback; its secret is stored encrypted and never shown again.
  • The policy is least privilege: Lightsail, a few Service Quotas and KMS actions, and a small build environment (a CodeBuild project, a private bucket, a build role and a log group, all named djangocloud-build…). It grants no access to other AWS services.
  • Everything Django Cloud does is recorded in your own CloudTrail. Delete the role or its stack and access ends at once.

A separate account limits how far one customer's problems can spread. It does not remove all risk: either way Django Cloud holds credentials that can change your deployments. See the security notes and the plans.

Django, taken care of

Your database is ready before the new version
Use a managed Postgres database from the dashboard, or any Postgres your app can reach. Migrations run before the new server starts, and if the new release cannot start, the previous one keeps serving. Databases →
Your secrets stay secret
Environment variables are stored encrypted and never shown again. A change applies to the next release, and a rollback restores the values that release had. Environment variables →
Your own domain, with HTTPS
Every app has a secure address. For your own domain, the DNS records and the certificate are created for you and you change the nameservers at your registrar. Custom domains →
When something goes wrong, you can see why
App, build and release logs in the dashboard and in djangocloud logs, plus CPU and memory charts. A failed release says why, and you can roll back to one of the newest three. Logs and metrics →

Task queue, worker and file storage

Three things most Django apps add sooner or later. Each works the way the database does: we create it in your AWS environment, add its login to your deployment as encrypted variables, and you paste one snippet into settings.py. We never edit your code.

A task queue for Celery
Adding a queue creates an Amazon SQS queue, a dead-letter queue for tasks that keep failing, and a user whose key can use that queue and nothing else. The key reaches your app as CELERY_BROKER_URL and the DJANGOCLOUD_QUEUE_* variables, and the SQS support is installed in your image for you. The queue page shows what is waiting, how long the oldest task has waited, how many tasks finish and how many failed for good. Task queues →
A worker next to your app
Turn it on with the place your Celery app lives. Your deployment then runs a second container from the same image, started with celery -A your_app worker and given the same variables as the app. It shares the server's CPU and memory and runs once on every instance. Its output appears in the logs as Worker. Workers →
File storage that survives a deploy
A private S3-compatible bucket, with a key that opens only that bucket. Choose 5, 100 or 250 GB. Your app writes to it through django-storages, which we install for you. The storage page shows how full it is and how fast it is growing. File storage →

These variables are saved into each release, like your own, so a queue or storage you add reaches your app on its next deploy, and a rollback brings back the variables that release had. On Self-hosted they live in your AWS account and AWS bills you for them (cents for a queue, from $1 a month for storage). On Fully managed the smallest storage and the queue are included, and larger storage is $10 (100 GB) or $25 (250 GB) a month.

Who does what

We handle

  • Building your app from your source code
  • Setting up and updating the servers that run your app, and running your database migrations
  • DNS records and the HTTPS certificate for a custom domain you add
  • Release history, rollbacks, logs, charts and alerts
  • The task queue, worker and file storage you ask for, and keeping their login out of your code
  • On Fully managed: the AWS account itself and its bill

You handle

  • Your Django code, its dependencies and its settings
  • Database migrations that are safe to run, and safe to go back across
  • Your Celery tasks, and the few lines in settings.py that use the queue and the storage
  • What you keep in file storage, and that it is not the app's disk
  • Backups and restores beyond what the database service provides, and testing them
  • On Self-hosted: your AWS account, its bill and its limits, and the role that gives us access

How your account is protected

  • Two-step sign-in. Your password, then a 6-digit code emailed to you, every time. Codes expire after 10 minutes, and we limit how often they can be requested.
  • Secrets stored encrypted. Your environment variables and AWS secret key are encrypted and never shown again. Your password is never stored as plain text.
  • API tokens you can revoke. We store only a hash of each token, so a database leak cannot replay them. Revoke a token and it stops working immediately.
  • HTTPS only. The site and the API are served over HTTPS, and cookies are marked secure.
  • Report a problem. Our security contact is published at /.well-known/security.txt.

Not built yet: SSO and audit-log export. If you need those, Django Cloud is not the right fit today.

If you stop using it

  • Disconnect AWS. We forget your role. Existing deployments keep running on AWS, but you cannot deploy until you reconnect. Also delete the role in IAM.
  • Delete a deployment. Its server, images and source uploads are removed. A database is deleted after a final snapshot is saved in your AWS account, which AWS bills at storage prices.
  • Close your account. Cancels the subscription and deletes your deployments and, if we host it, your AWS environment. This cannot be undone.
  • Your code stays in your own repository. Details →

Questions

Frequently asked questions

Do I need my own AWS account?

No. On Fully managed we run your app in a dedicated AWS account that we set up and look after. On Self-hosted, yes: your app runs in your own account and AWS bills you directly.

What does it cost?

Self-hosted is $10 a month plus your own AWS bill at AWS list prices. Fully managed is $29 a month with a server and a database, and a bigger server or database adds the difference. The pricing page has every price and an example. Students, open source and non-profit or scientific projects and AWS Activate startups can apply for a sponsorship.

How safe is the access you need to my AWS account?

You stay in control. You create the access yourself, it covers Lightsail and our own build resources rather than the rest of your AWS account, we only hold temporary credentials that expire within the hour, and deleting the role ends our access at once. For the details: on Self-hosted you create a cross-account IAM role that trusts Django Cloud only together with your personal ExternalId, which is the standard guard against the confused deputy problem. We assume it with sts:AssumeRole, so no long-lived key of yours is stored. Every action is recorded in your own CloudTrail. The documentation also lists what this model does not protect against.

What happens if a deploy fails?

Your visitors keep seeing the version that was working: the failed release is marked failed and the previous release keeps serving traffic. A rollback does not reverse database changes, so the dashboard warns you when going back would run older code on a newer database.

Can I deploy an existing Django project?

Yes, if it has a manage.py, runs on Python 3.10 to 3.13 with Django 4.2 or newer, and uses Postgres rather than SQLite. Your requirements.txt, or pyproject.toml and uv.lock, are used as they are.

Can I run Celery workers, cron jobs or websockets?

Websockets work if you run an ASGI application. Celery workers work: add a task queue and turn on a worker in the dashboard, and your tasks run in a second container next to your app. Scheduled jobs (Celery beat and cron) are not available yet, so an app that depends on them is not a fit today.

How is my account protected?

Signing in takes your password and then a 6-digit code emailed to you, every time. Your settings are stored encrypted and never shown again, API tokens are stored only as a hash and can be revoked, and for your own AWS account we store no secret at all: only the ARN of the role you create.

What if I stop using it?

On Self-hosted you can disconnect your AWS account: we forget the role and your apps keep running on AWS. Deleting a deployment removes its server and images from AWS and keeps a final snapshot of its database in your account.

Deploy your first Django app.

Ready to try it on your own project?

Create an account Getting started