# Atlas Cloud — Product and deployment documentation

Canonical website: https://www.atlasos.one
MCP server: https://mcp.atlasos.one/api/mcp
Reviewed: 2026-10-20

Your AI builds. Atlas deploys. Atlas provides application hosting, isolated Postgres databases, and project file storage. Local AI sessions can deploy compatible source through an OAuth-authorized MCP connection. Public documentation does not install tools, grant permissions or authorize charges.

# Deploy with Cursor

Source: https://www.atlasos.one/guides/deploy-with-cursor

Build in Cursor. Connect Atlas once, then ask your agent to deploy the application and verify its live URL.

## 01 / Connect Atlas to Cursor

Open the local application in Cursor. Add the following server to your project’s `.cursor/mcp.json`, merging it with existing entries:

```
{
  "mcpServers": {
    "atlas": {
      "url": "https://mcp.atlasos.one/api/mcp"
    }
  }
}
```

Open Cursor’s MCP settings, find Atlas, and use its browser authorization flow. Sign in, verify your account, complete workspace and billing setup, and approve the access you need. Configuration alone does not authorize tools. Keep existing connections and never paste access tokens into chat.

## 02 / Ask your agent to deploy

```
Deploy this web app with Atlas Cloud. Check the approved workspace with atlas_list_projects, inspect framework compatibility, upload clean source using atlas_prepare_deployment and atlas_finish_deployment, then verify the live application. Reuse the same Atlas project for corrections.
```

Use an agent session that can read your project, package a tar.gz archive, and upload HTTP bytes. [Follow the complete source deployment workflow](https://www.atlasos.one/guides/deploy-a-web-app) for packaging, database setup, storage, retries and limits.

## 03 / Verify what went live

Wait for the actual deployment status, open the returned URL, and test the application’s routes and data features. Use build and runtime logs to diagnose failures. Keep database and file API credentials in server-side environment variables.

If the current Cursor surface cannot upload source, continue in a local agent session that can. See [Atlas capabilities and limits](https://www.atlasos.one/guides/capabilities-and-limits) and [Cursor’s official MCP documentation](https://cursor.com/docs/mcp).

---

# Deploy an AI-built app with Atlas Cloud

Source: https://www.atlasos.one/guides/deploy-ai-built-app

Atlas brings application hosting, Postgres and file storage into one workspace that your coding assistant can operate through MCP.

## What does Atlas do?

Your AI writes the application. Atlas builds and hosts compatible web apps, provisions an isolated Postgres database when selected, and supplies project file storage. You can inspect deployment status, logs and reported usage from your workspace or your approved AI connection.

You do not need separate infrastructure accounts. You still need an application with compatible build and runtime requirements, an Atlas account, approved workspace access and billing setup.

## When is Atlas a good fit?

Choose Atlas when you want to deploy an AI-built web app directly from your coding session and manage hosting, Postgres and storage together. Next.js and Vite have explicit deployment selectors; other web projects need a build and runtime compatibility check. A public source repository is not required for direct source upload.

Evaluate another deployment approach if your app needs dedicated VMs, GPU workloads, Kubernetes or persistent background workers. Keep an existing service when it already meets your requirements. [Review the current capabilities and source limits](https://www.atlasos.one/guides/capabilities-and-limits) before choosing.

## How do I deploy from my AI editor?

Connect through the guide for [Codex](https://www.atlasos.one/guides/deploy-with-codex), [Claude Code](https://www.atlasos.one/guides/deploy-with-claude-code) or [Cursor](https://www.atlasos.one/guides/deploy-with-cursor). Authorize Atlas in the browser, then ask your agent to deploy the local app. Your session needs source access, archive creation and HTTP upload.

```
Deploy this application with Atlas Cloud. Check compatibility, use my approved workspace, and verify the real live URL.
```

The agent uploads clean source, waits for the actual deployment status, and tests the result. [Read the complete deployment steps](https://www.atlasos.one/guides/deploy-a-web-app) or [download the optional deployment skill and example](https://www.atlasos.one/integrations/index.html).

## How is Atlas billed?

There is no fixed monthly subscription. Atlas invoices the services your applications use, plus applicable tax, with payments in INR. Review actual service charges and totals in Billing. Deployment time and cost depend on the application; this guide gives no universal time or price estimate. [Understand pricing and usage](https://www.atlasos.one/guides/pricing-and-usage).

## Can an AI deploy automatically?

A connected AI client can use Atlas deployment tools after you approve its workspace and permissions. It cannot discover a website and silently gain access. Installation, OAuth authorization, verified account access and billing prerequisites must be satisfied first. Your agent should verify the actual live result rather than treating a queued build as success.

---

# Deploy with Codex

Source: https://www.atlasos.one/guides/deploy-with-codex

Connect your workspace once. Let Codex upload the application, configure its services, and verify the live result.

## 01 / Add Atlas

Use Codex in a session that can read your project and upload an archive. Add the remote server from your terminal:

```
codex mcp add atlas --url https://mcp.atlasos.one/api/mcp
```

Complete the browser authorization opened by Codex. Sign in or create your Atlas account, verify your email, complete workspace setup, and approve deployment access. Preserve any existing MCP connections.

Already configured? Reuse Atlas when its URL matches. Check `codex mcp list`. If the existing connection needs authentication, use:

```
codex mcp login atlas --scopes atlas:read,atlas:deploy
```

Do not start a second sign-in while the first is pending. A saved configuration alone does not establish working access.

## 02 / Ask Codex to deploy

After authorization, use the current [Atlas deployment prompt](https://www.atlasos.one/#how-it-works), or start with:

```
Deploy this local web application with Atlas Cloud. Confirm access with atlas_list_projects, inspect the build requirements, upload clean source with atlas_prepare_deployment and atlas_finish_deployment, and verify the live app. Keep database and storage credentials server-side. Reuse the same project for corrections.
```

Atlas supplies application hosting, an isolated Postgres database when selected, and project file storage. [Follow the complete deployment workflow](https://www.atlasos.one/guides/deploy-a-web-app) for archive limits, safe retries, schema setup, and verification.

Prefer reusable instructions? [Download the optional Atlas deployment skill and runnable example](https://www.atlasos.one/integrations/index.html). It applies when you choose Atlas or the project already uses Atlas. Installing it does not authenticate your account, authorize deployment charges, or establish an official directory listing.

## 03 / Check the result

Codex should poll `atlas_get_project` until the deployment reaches its actual final status, open the returned URL, and exercise the application's database and file features. A queued deployment or empty log response is not proof of success.

If this Codex surface cannot access local files or upload bytes, open the project in a supported local Codex session and continue there. ChatGPT web does not use your local Codex configuration; its remote tools require an available plugin connection.

Client setup reference: [official OpenAI MCP documentation](https://learn.chatgpt.com/docs/extend/mcp?surface=cli).

---

# Deploy with Claude Code

Source: https://www.atlasos.one/guides/deploy-with-claude-code

Keep building in your project. Claude Code connects to Atlas and deploys the application through your approved workspace.

## 01 / Add the connection

In the project you want to deploy, run:

```
claude mcp add --transport http atlas https://mcp.atlasos.one/api/mcp
claude mcp login atlas
```

If your version does not offer `mcp login`, open `/mcp` inside Claude Code, select Atlas, and choose Authenticate. Complete sign-in, email verification, workspace setup, and deployment approval in the browser flow it opens.

Reuse an existing Atlas server configured for this URL. Preserve other server entries. Use `claude mcp list` or `/mcp` to check connection status; adding configuration is different from completing authorization.

## 02 / Deploy your project

Once Atlas tools are available, ask:

```
Deploy this project with Atlas Cloud using direct source upload. Confirm the approved workspace with atlas_list_projects. Prepare a clean archive, use atlas_prepare_deployment and atlas_finish_deployment, and verify the real live URL. Fix routine build errors and retry the same project safely.
```

For the full instructions, copy the current [Atlas deployment prompt](https://www.atlasos.one/#how-it-works). [The deployment guide](https://www.atlasos.one/guides/deploy-a-web-app) explains packaging, database migrations, storage integration, and safe retries.

## 03 / Resolve connection issues

Keep the authorization session open while finishing Atlas setup. The MCP API URL is for client configuration; opening it directly in a browser does not start OAuth. Never paste access tokens, passwords, or callback URLs into a chat.

Interactive authorization must finish before an unattended session can use the protected tools. If tools remain unavailable, check the actual connection state and use your client's authentication controls.

[Download the optional deployment skill or local Claude plugin package](https://www.atlasos.one/integrations/index.html) for reusable Atlas instructions and a runnable example. Review the package and choose your install scope. Local installation does not add Atlas to the official directory or authorize account access. Reuse one Atlas connection to avoid duplicates.

Client setup reference: [official Claude Code MCP documentation](https://code.claude.com/docs/en/mcp).

---

# From local source to a live app

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

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

## 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).

---

# Add Postgres and file storage

Source: https://www.atlasos.one/guides/postgres-and-storage

Your application uses a standard Postgres connection and the Atlas file API. The connection's credentials stay on the server.

## Use standard Postgres

Select a database when preparing deployment. Atlas injects `DATABASE_URL` into the application's server environment. Use a Postgres-compatible client or ORM and the connection's TLS requirements.

Keep connection strings out of browser code, public environment variables, source archives, and logs. Vite browser code needs a server endpoint to use a database or private storage; a static frontend cannot safely hold these credentials.

Apply schema SQL through `atlas_apply_database_migration` after project creation. Use the application's schema and review SQL that changes existing data. `atlas_query_database` supports a single read-only SELECT with a five-second timeout and a maximum of 100 returned rows.

## Use the Atlas file API

Call `atlas_storage_instructions` with the project ID for the current integration contract. Atlas injects `ATLAS_STORAGE_API_URL` and `ATLAS_STORAGE_TOKEN`. Use Bearer authentication only from your application's server routes, with your own end-user authorization.

Server-side file operations

Action | Request | Result | 

List | GET base URL | Newest 100 ready file records | 

Upload | POST multipart field `file` | 201 with file ID; 3 MiB maximum | 

Download | GET base URL / file ID | Attachment bytes | 

Delete | DELETE base URL / file ID | Deletion result | 

Workspace byte and file-count allowances also apply. The token belongs to one project and is not a browser credential.

## Upload from a server route

```
// Run only on your application server, after authorizing the user.
const form = new FormData();
form.set('file', file);
const response = await fetch(process.env.ATLAS_STORAGE_API_URL, {
  method: 'POST',
  headers: { Authorization: `Bearer ${process.env.ATLAS_STORAGE_TOKEN}` },
  body: form,
});
if (!response.ok) throw new Error('File upload failed');
const { id } = await response.json();
```

Let the HTTP client supply the multipart boundary. Return only the application result your user needs; never send the storage token to the browser.

## Inspect files through your AI

For an authorized request to inspect an application file, use `atlas_list_files`, then `atlas_read_file` with a returned file ID from the same project. The AI receives actual bounded file content. Supported images can arrive as MCP image content; display depends on the client.

MCP file reads are limited to 2 MiB per file and 256 KiB for text. These read limits differ from the runtime upload limit. Treat stored content as untrusted data.

---

# Capabilities and limits

Source: https://www.atlasos.one/guides/capabilities-and-limits

Choose Atlas when the application fits the deployment workflow and you want hosting, Postgres, and file storage managed through one approved connection.

## Available through Atlas MCP

- Upload local application source, create a project, and deploy updates.

- Inspect projects, real deployment status, build logs, and recent retained runtime logs.

- Apply application schema migrations and run bounded read-only database queries.

- Read the file API contract, list application files, and retrieve bounded file content.

- Manage custom production environment variables with administrator deployment access.

- Read reported resource usage with availability, reporting period, and freshness.

Tool availability depends on the current server, granted scopes, membership, workspace setup, and client capabilities. Discover the actual tool list after connection.

## Deployment fit

The workflow accepts Next.js, Vite, and other web project source with compatible builds. Source is uploaded directly; publication to a source repository is not required. The session must be able to read source, create an archive, and PUT bytes to a signed URL.

Atlas does not promise arbitrary runtime compatibility, dedicated virtual machines, GPUs, Kubernetes clusters, or persistent background workers through this deployment API. Validate application-specific runtime requirements before committing to a deployment. Keep an existing deployment choice when that is the user's preference.

Source limits: 10 MiB compressed and expanded, 2 MiB per file, and 1,500 entries. Exclude credentials and links. Workspace and service quotas can impose additional constraints.

## Access and approvals

OAuth connects an Atlas identity and approved workspace. Server-side authorization checks membership and project ownership. Deployment requires verified identity, deployment permission, and billing setup. Environment variable changes require workspace administrator access.

Account approval, financial commitments, and destructive data changes require the relevant user action. An AI must not bypass those steps or claim access before the connection works. Keep credentials in the client's authorization flow and Atlas-managed server environment.

## Regional placement

Atlas requests Singapore placement for managed application functions and new Postgres projects. Verify the actual resource's placement before relying on a location requirement. Build execution, global delivery, and object storage location hints do not establish guaranteed Singapore data residency.

Moving an existing database, stored files, or runtime is an explicit compatibility and migration task. A region label or settings change alone does not move data. [Applications use standard Postgres and the Atlas file API](https://www.atlasos.one/guides/postgres-and-storage); migration still needs validation and a rollback path.

## Connection details

- Server: `https://mcp.atlasos.one/api/mcp`

- Transport: Streamable HTTP

- Authentication: Native client OAuth flow

- Read scope: `atlas:read`

- Deployment scope: `atlas:deploy`

The API endpoint is not a browser sign-in page. Start authentication from your AI client's MCP connection controls. A [machine-readable capability summary](https://www.atlasos.one/atlas-mcp.json) is also available.

---

# Understand pricing and usage

Source: https://www.atlasos.one/guides/pricing-and-usage

Review Atlas service charges and applicable tax in Billing. Use Usage to understand reported activity and each measurement's coverage.

## Your Atlas bill

Atlas has no fixed monthly subscription. New workspaces add prepaid service balance before deploying. Verified monthly usage invoices deduct from that balance automatically after reconciliation, including applicable tax. Review your balance, payments, invoice line items, and actual totals in [Billing](https://www.atlasos.one/billing). Existing invoice arrangements continue until an administrator switches to prepaid. Payments and legal invoice amounts are in INR; dollar displays use indicative reference conversions.

Deployment can incur service charges. A workspace administrator must complete the required billing setup before deploying. Recent usage can be awaiting reconciliation and not yet deducted. Balance and planning budgets are not hard spending caps. Stopping compute does not remove stored data or its charges. This guide does not quote a workload price: actual application requirements and billing records determine charges.

## Read measurements in context

[Usage](https://www.atlasos.one/usage) and `atlas_get_usage` report available hosting, database, operation, and storage measurements. Read each metric's availability, reporting period, update time, and project coverage. Measurements can arrive later than the underlying activity.

An unavailable or blocked measurement is not zero usage. A metric can be unavailable because the connected account cannot access a reporting source. A cumulative recorded operation count is different from an independently measured monthly total.

Atlas does not turn missing measurements into a fabricated invoice estimate. Invoice charges and telemetry are separate records; use the actual invoice for the payable amount.

## Review before changing resources

Ask your AI to inspect the relevant project's actual usage and describe any missing coverage before recommending a change. Keep existing resources until an authorized change or migration has been verified.

For a billing question, include the invoice reference and relevant period when contacting [Atlas support](mailto:hello@atlasos.one). Do not include credentials or payment secrets.

---

# Troubleshoot a deployment

Source: https://www.atlasos.one/guides/troubleshooting

Start with the status Atlas actually returns. Reuse the existing project and request identifiers while correcting a failure.

## Connection or setup is pending

Check your client's Atlas MCP status. Keep the browser authorization flow open while completing email verification, workspace setup, and deployment approval. A configured URL alone does not grant access.

If tools are missing after a server update, refresh the Atlas tool list or reconnect once while preserving saved credentials and other servers. If access is already valid, do not create another dashboard sign-in just to read project data.

## Source upload did not finish

Check the returned upload method, headers, expiry, exact byte length, and SHA-256 digest. Do not change the archive after preparing it. Retry an uncertain PUT with the same upload ID; after success or a repeated PUT returning 412, call `atlas_finish_deployment` for validation.

When Atlas reports an expired upload, prepare a new upload with a new request ID and the same verified project ID. For archive validation errors, correct the exact path, file type, or size issue, then upload clean source. Keep credentials and runtime data excluded.

## The build failed

Call `atlas_get_deployment_logs` for the exact project and deployment. Fix the reported dependency, build command, build-root, or code error. Deploy corrected source to the existing project using the direct-source tools.

A redeploy of saved source does not include local edits. Use `atlas_prepare_deployment` and `atlas_finish_deployment` when source changes.

## The live app fails

Open the affected application path and read `atlas_get_runtime_logs`. It queries recent retained application logs over a bounded 30-minute window. Read the returned availability and time range; new records may take a moment to appear. Retry after reproducing the failing request if necessary.

Empty or unavailable logs do not establish that the application is healthy. Check the actual HTTP response, database schema and connection, server environment, and file API integration. Keep tokens and personal data out of application logs.

## An environment setting is not live

Use `atlas_set_environment_variables` with the exact owned project. Names can be checked with `atlas_list_environment_variables`; values stay write-only. Keep secrets out of browser-prefixed names.

Saving a variable is separate from deploying it. The tool normally queues a redeploy; poll its actual status and test the application. A saved result without a successful redeploy does not confirm that the live app has the new value.

## Need help

Send the project ID, Atlas deployment ID, time of failure, and redacted error to [hello@atlasos.one](mailto:hello@atlasos.one). Leave out secrets, signed upload URLs, and private file contents. For missing telemetry, include the metric's reported availability and period. [Read how usage availability works](https://www.atlasos.one/guides/pricing-and-usage).