Guides / Deploy Django to your client's AWS account with Django Cloud Self-hosted

Peter van Doorn Django Cloud · Checked against Django 4.2 and newer, October 2026

Deploy Django to your client's AWS account with Django Cloud Self-hosted

Many clients, especially larger ones, will not let an outside developer's account host their app. They want it in their own AWS account, and they want to keep the keys. That is a good request. Here is how access works safely, and what each side does.

The pattern: a cross-account role, not a shared password

Never ask a client for an access key or their root login. AWS has a better tool: an IAM role in the client's account that your tooling is allowed to assume.

• The client creates the role. They decide what it can do.
• The role trusts one outside account and requires a secret value called an ExternalId. This stops another party from tricking your tooling into acting on the client's account (the "confused deputy" problem).
• The outside party receives temporary credentials that expire, not a permanent key.
• Every action is written to the client's own CloudTrail log.
• The client ends access any time by deleting the role.

Steps for the client

1. Create or choose an AWS account for the app. A separate account per application keeps the bill and the permissions clean.
2. Add a payment method. AWS bills the account owner directly.
3. Open the CloudFormation link from Django Cloud. AWS opens it with everything filled in; the client reviews it and creates the stack.
4. The connection completes by itself when the stack finishes.

Steps for you

1. Create the project in Django Cloud and choose the Self-hosted plan.
2. Send the client the connection link, and ask them to share the AWS account ID when done.
3. Pick the region the client's contract or policy requires.
4. Deploy as usual:

pip install djangocloud-cli
djangocloud login
djangocloud env push .env
djangocloud deploy

What the client can check

• The role and its permissions in IAM, in plain JSON.
• Every call made through it in CloudTrail.
• The servers and databases in the Lightsail console, as ordinary resources.
• The bill in AWS Billing, at AWS list prices.

What it does not protect against

A role limits what an outside party can do; it does not make that party trustworthy. Anyone who can deploy can run code in the account, within the role's permissions. Treat the access like you would treat a contractor with a key: grant the minimum, review it, and remove it when the work ends.

When the contract ends

The client deletes the role. The app keeps running in their account, and they keep the servers, the database and the data. See the handover checklist for the rest.

Questions

Does the client have to give me an access key?

No. The client creates a role and your tooling assumes it. No long-lived key is stored, and the client can delete the role at any time.

What if the client leaves Django Cloud?

Existing deployments keep running in their AWS account. Without the role they cannot deploy through Django Cloud until they reconnect.

Or skip it

Django Cloud Self-hosted connects to your client's AWS account through a role they create from one CloudFormation stack, trusted only together with their personal ExternalId. We hold temporary credentials, every action shows in their CloudTrail, and deleting the role ends our access.

pip install djangocloud-cli
djangocloud deploy

Get startedSee pricing

Free plans are available for students, AWS Activate startups, open-source, non-profit and research projects. See how Django Cloud compares with other ways to host Django.

Django is a registered trademark of the Django Software Foundation. Django Cloud is not affiliated with or endorsed by it. Found a mistake in this guide? Tell us and we will fix it.