# From local source to a live app

Upload the application you are building. Atlas creates the project services and returns the deployment's actual status.

Atlas Cloud · Reviewed 2026-10-20

## Start with an approved connection

Connect with [Codex](https://www.atlasos.one/guides/deploy-with-codex) or [Claude Code](https://www.atlasos.one/guides/deploy-with-claude-code). The session needs local source access, archive creation, and an HTTP upload capability. Your Atlas account must be verified, your workspace must allow deployment, and a workspace administrator must complete billing setup.

Call `atlas_list_projects` to confirm access before inspecting the application. For an update, identify this application's existing project and use its exact `projectId`.

## 01 / Package clean source

Inspect the framework and build requirements. Choose `nextjs`, `vite`, or `other`, and a build root relative to the archive's project root. Other frameworks require compatible build and runtime behavior; the label alone does not establish support.

Create a gzip tar archive with one `atlas/` root. Exclude credentials, `.env` files, Git metadata, dependencies, build output, caches, platform metadata, runtime data, and filesystem links. Include the application files and dependency lockfile needed for a reproducible build.

- Archive / expanded source: 10 MiB each

- Individual file: 2 MiB

- Archive entries: 1,500 maximum

Calculate the archive's exact byte length and lowercase SHA-256 digest.

## 02 / Prepare, upload, finish

- Call `atlas_prepare_deployment` with the name, framework, `rootDirectory`, database choice, archive byte length and digest, and a new UUID `requestId`. Include the verified `projectId` when updating.

- Use the returned project name and ID. Upload the exact archive bytes to the temporary `uploadUrl` with its method and every returned header before expiry. Keep signed URLs out of replies and logs.

- Call `atlas_finish_deployment` with the same `uploadId`. Atlas validates the bytes and digest, then queues the deployment.

- Poll `atlas_get_project` until Ready or Failed. Follow actual tool results when setup, quota, or permission requirements block progress.

After an uncertain upload response, reuse the same upload and request identifiers. An HTTP 412 from a repeated PUT can mean the upload already exists; let `atlas_finish_deployment` validate it. Do not create duplicate projects to resolve an uncertain result.

## 03 / Connect application features

Atlas injects `DATABASE_URL` when a database is selected, plus `ATLAS_STORAGE_API_URL` and `ATLAS_STORAGE_TOKEN` for project file storage. Keep these in server-side code. [Read the integration guide](https://www.atlasos.one/guides/postgres-and-storage) before adapting database or upload routes.

Use `atlas_apply_database_migration` to apply schema SQL only to this project's isolated database. Review and obtain approval before destructive changes to existing data. Use `atlas_query_database` for a bounded read-only verification.

## 04 / Verify the application

Fetch or open the actual new deployment URL. Test a real application path, a database write and read if applicable, and a file upload and retrieval if applicable. A successful build alone does not verify these features.

For a failed build, read `atlas_get_deployment_logs`, fix the reported error, then upload changed source to the same project. For application errors, use `atlas_get_runtime_logs` and read its availability and time window. Return the verified live URL, [Usage](https://www.atlasos.one/usage), and [Billing](https://www.atlasos.one/billing).

Canonical: https://www.atlasos.one/guides/deploy-a-web-app