Docs

Deploying an app

An app on anywhere is a folder with an app.toml. The folder’s name is the app’s name: lowercase letters, digits and hyphens, starting and ending with a letter or digit. AI agents deploy apps with the anywhere CLI, and so can you.

Get started

The fastest way: paste this into Claude Code, Codex, Cursor or any agent that can run commands and open a link.

Set up anywhere for me: https://anywhere.so/setup

Your agent reads the setup page, installs the CLI and its skill, gives you a link to sign in, which makes your account if you’re new, and asks what to build. To do it yourself instead:

1. Install the CLI and its skill. In a terminal, run:

   curl -fsSL https://anywhere.so/install.sh | sh
   

   It runs on macOS 13 or later and on Linux on x86_64. It installs anywhere into ~/.local/bin, and the anywhere skill for Claude Code and Codex, which tells your agent how to deploy. If your shell can’t find anywhere afterwards, the installer’s last lines say how to put ~/.local/bin on your PATH.

2. Sign in. Run:

   anywhere login
   

   It prints a link and a code, and opens the link in your browser when it can. Sign in, check the page shows the same code, and approve.

3. Ask your agent (Claude Code or Codex) to build and deploy something. It appears on your home screen at anywhere.so. Other agents can read the skill at ~/.agents/skills/anywhere/SKILL.md.

When a command fails with cli_outdated, the platform has changed since you installed the CLI: run the install command again, which updates the CLI and its skill.

Describe the app

Put an app.toml at the top of the folder. It names the app and says how to build and start its web server:

title = "Spending"
build = "npm ci" # optional; runs on every deploy

[processes]
web = "node server.js"

The server must listen on 0.0.0.0, on the port in the PORT environment variable.

For a background process, use worker instead of web; it must keep running and has no web address. For a static site, use static = "dist" at the top level instead of [processes]. Build dependencies inside the app and leave local dependencies, secrets and runtime data out of the upload with .gitignore.

Set limits, if you want them

An app can use up to its plan’s limits: on Free, 1 shared vCPU, 2 GiB of memory and 10 GiB of disk; on Pro, 4 shared vCPUs, 16 GiB of memory and 100 GiB of disk. Its build, the running app and commands from anywhere exec share them. Limits are caps, not reservations: you pay for what the app uses, not its limits. Most apps never need to set any.

To keep an app below its plan’s limits, add this table after the app’s other settings. Each line is optional:

[limits]
cpu = 2           # vCPUs it may use at most; a decimal such as 0.5 is fine
memory = "4 GiB"  # most memory it may use; past this, it's restarted
disk = "20 GiB"   # most disk it may hold

Memory and disk take MiB or GiB. A deploy that asks for more than the plan allows fails with limit_above_plan, which names the limit, the plan’s ceiling and the fix. A build that needs more memory than the app’s limit fails with build_out_of_memory, which names the limit and how to raise it. Disk can go down as well as up, as long as the app’s data still fits; otherwise the deploy fails with disk_limit_below_used, saying how much the app holds.

Plans and usage

Each plan includes usage every month. Your apps use it for what they actually use: memory and CPU while they run, the disk they hold, and the data they send out. Data coming in is free.

Free is for trying anywhere: it includes 3 apps. A deploy that would make a fourth app fails with plan_app_limit: “Free includes 3 apps; delete one, or upgrade to Pro for any number.” Deleting an app frees its place. Moving from Pro to Free never removes an app; it only stops new ones while you have more than 3.

Usage is charged each hour at these rates:

Each hour is charged at the rates in effect for that hour, so a change to the rates never re-prices usage already charged. For example, our sample web app, samples/node-web, awake all month with no visitors, uses about 46 MiB of memory and under 1 MiB of disk, which comes to about $0.84 a month, measured over its charged hours on our own stack. Each GiB it sends out adds $0.20. Yours will differ: anywhere usage prints what your account has used this month, and anywhere usage APP --detail one app’s cost by memory, CPU, disk and data out.

You’ll never pay more than your plan unless you add more yourself. The month is the calendar month in UTC.

• At 75% and 90% of the month’s usage, the portal shows a warning, and the CLI prints one.
• At 100%, your apps pause. Their disks and data are kept, and visitors see “This app is paused”. Deploys and anywhere exec fail with usage_limit_reached, which says how much was used, when the month resets and how to upgrade.
• Paused apps start again by themselves on the 1st, or as soon as you upgrade or add a top-up. An app you stopped yourself stays stopped.

On Pro, you can add a top-up of $10 or $25 at anywhere.so/billing. Top-ups never expire, and they’re used only after the month’s included $20, which doesn’t carry over. Free can’t buy one: it fails with topup_requires_pro, which links to upgrading. If anywhere’s operators have switched off the pause at 100% in an emergency, nothing pauses, so buying a top-up fails with topups_not_needed.

Sharing is free. An app’s usage counts against its owner’s plan, including deploys by its developers. A developer never sees what the owner’s apps cost.

To upgrade, open anywhere.so/billing, signed in, and press Upgrade to Pro. You pay on Stripe’s checkout page, where Pro is sold through Link, from Stripe, which sends your receipts and answers questions about payments and refunds. Stripe then sends you back to /billing, which shows Pro. Manage billing on the same page opens Stripe’s billing page, where you change your card or cancel; you can also manage or cancel the subscription at link.com. When the subscription ends, your account returns to Free.

A plan change deletes nothing. Each app keeps its limits until its next deploy, which applies the new plan’s.

Agents don’t pay. An agent whose apps are paused, or whose deploy asks for more than the plan allows, tells you, and if you want more, sends you to https://anywhere.so/billing to upgrade or add a top-up yourself. It never enters payment details.

Deploy

From the folder, run:

anywhere deploy

The CLI uploads the folder’s included files, replaces those files in /app, runs the build and starts the app. It prints the operation ID and progress, then the web app’s address. Background apps show their output through anywhere logs --app NAME and the portal’s app page.

The app’s disk persists across restarts and deploys, including installed packages and data. A deploy replaces uploaded files and deletes nothing else; keep databases and other live data out of the upload. Deploys do not create rollback versions. If a build fails, the app retains the new files and any work the build completed.

To change an app’s limits later, change [limits] and deploy again, which restarts it on its disk.

Open a private app

Open the returned URL and sign in to Anywhere. The app is private to its owner until shared with another Anywhere account. If the app has its own login, use it afterward: its cookies and native authorization work alongside the Anywhere session.

An app can embed its own pages and documents, subject to its own security policy. A sandboxed embedded page can send requests without the Anywhere credential; those requests cannot inherit the signed-in parent’s access. Ordinary same-origin forms work, but each embedded workflow needs checking. Public webhooks and scoped app-to-app access are not available yet.

Find a failure

When a deploy fails, the CLI prints error: <code>: <message>, and the message says how to fix it.

Read anywhere logs --app NAME for recent app and build output, and use anywhere --json apps inspect NAME for structured status. If the connection drops after an operation ID was returned, check anywhere operations get ID --wait before repeating the change.

App logs are bounded and do not include requests refused by the gateway before reaching the app. For a failed browser action, inspect the response’s status and error code too. A successful deploy does not prove that every screen or workflow works.

Delete an app

Delete an app from its page in the portal, or with:

anywhere apps delete NAME

At a terminal, it asks you to type the app’s name; an agent, which has none, passes --yes. Its address and every share of it go at once, and its name is free, so a later deploy by that name makes a new app on an empty disk. Nothing restores a deleted app. Its files and secrets stay on our servers, where nothing reaches them; to have them erased, email [email protected]. Only its owner can delete it, and not while a deploy of it is under way.