> For the complete documentation index, see [llms.txt](https://django-cloud.gitbook.io/django-cloud-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://django-cloud.gitbook.io/django-cloud-docs/how-it-works/overview.md).

# From code to a live URL

Every deploy, whether it starts from `djangocloud deploy` or a push to GitHub, goes through the same steps.

1. **Source.** Your code arrives as an upload from the CLI, or is fetched from GitHub with a short-lived read-only token.
2. **Release.** DjangoCloud creates a numbered release (v1, v2, ...) and snapshots your [build settings](/django-cloud-docs/how-it-works/build-settings.md) and [environment variables](/django-cloud-docs/how-it-works/environment-variables.md) into it.
3. **Build.** A container image is built from your settings in a throwaway AWS CodeBuild container in your account. The build gets your source and a temporary push-only login to your Lightsail image registry, and nothing else. A build that runs too long is stopped (see [Known limitations](/django-cloud-docs/reference/limitations.md)).
4. **Deploy.** The image is registered with your Lightsail container service and deployed to it. Your release command, by default `python manage.py migrate --noinput`, runs when the container starts, before the server. See [How your app is run](/django-cloud-docs/how-it-works/how-your-app-runs.md).
5. **Health check.** DjangoCloud waits until your app answers on its health check path, then marks the release **active** and the previous one **superseded**.
6. **Live.** Your app is served over HTTPS on its public URL.

If any step fails, the release is marked **failed** and the previous release keeps serving traffic.

## Where things run

* **Your app, and its servers,** run in your AWS account, in the region you chose.
* **DjangoCloud** handles builds, release history, the dashboard and billing.
* Your AWS access key is encrypted at rest and used only to create and update your deployments.

## What you can follow

The dashboard shows each deployment's overview and server details, **Logs** with search, **Metrics** with CPU and memory charts you can hover, **Releases** with a Roll back button, **Environment** variables, **Domains** and settings. See [Logs and metrics](/django-cloud-docs/how-it-works/logs-and-metrics.md). The CLI streams a release's progress to your terminal while it builds, and `djangocloud status` and `djangocloud logs` show the same from the terminal.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://django-cloud.gitbook.io/django-cloud-docs/how-it-works/overview.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.