--- topic: prerequisites --- [← Guide home](https://embarko.ai/docs) # Before you start **On this page:** What Embarko is, Hosts you may need to reach, Talking to the person, Which route, Does the app fit?, What each route accepts Embarko hosts apps that an AI agent built. You deploy; the person gets a live link at {name}.embarko.app. They are usually not a developer, so you do the hosting work and tell them the result in plain words. **What Embarko is** - Hosting for AI-built apps: static websites and one-process server apps. - Languages: node, python, go, ruby, php, rust, java, static. - Address: {app-name}.embarko.app, or the person's own domain. - First deploy: Needs no account. It is temporary (24 hours) until claimed, unless it went through the connector. **Hosts you may need to reach** (all Embarko; allowlist them together) - `ship.embarko.ai`: The API: deploy, status, logs and every management call. - `embarko.ai`: The website: human docs, sign-in, the dashboard, deploy tokens, Showcase pages. - `{app-name}.embarko.app`: Where each deployed app is served. Open it to check the app works. - `raw.githubusercontent.com / github.com`: Only for the optional skill and its deploy script (github.com/embarko-ai/skill). **Talking to the person** Reply in 1-3 short plain sentences: what happened, and what the person needs to do only if something is needed. Do not show commands, API names, tokens, headers or logs, or describe the steps you took, unless the person asks for technical details. If the person is clearly a developer (uses technical terms, asks what you ran), talk to them that way for the rest of the conversation. Never show a token. Never invent a link, name or code: use only what Embarko's replies, this guide or the person give you. If the person asks what you ran or wants technical details, tell them plainly: commands, replies and logs are fine then. Never show a token. Say: Live · Open app · Deploy · Update · Needs attention · Fix with your AI Avoid: Provision · Runtime · Container · Build log · Endpoint · Deployment artifact · Infrastructure · Resource allocation · HTTP status codes Never ask: - Which port, framework, runtime or build command to use: work it out from the code. - Whether to add a Dockerfile: never add one. - Permission to continue a deploy they already asked for. - For a token before anything is live: deploy first, ask later. Ask only for: - Their identity: an email to keep the app. - A secret only they have, such as their own API key. - Access only they have, such as adding a DNS record for their domain. - A consequential decision: deleting, changing the address, going public, or spending money. Ask for that one thing, then carry on without further questions. Always tell them: - When a temporary app will be deleted (the exact time from app.expiresAt). - When something needs them, and what exactly. - When Embarko cannot do what they asked, and what you will do instead. **Stop when it works.** When the person's request works, stop. Do not suggest other Embarko features (connector, Showcase, domains, plans) they did not ask for. Telling them when a temporary app will be deleted, and offering once to keep it, is part of the job, not a pitch. Examples: - deploying: "Your app is deploying now. I'll tell you when it's live." - live: "Your app is live: {link}. It stays online until {time}; want me to keep it permanently?" - live_owned: "Your app is live: {link}." - still_building: "Still building. Nothing needed from you." - failed: "It didn't go live because of a problem in the code. I'm fixing it now." - needs_user: "I need one thing from you: {plain explanation}." - missing_secrets: "Your app needs a key before it can work. Add it here: {secrets page link}" - connect_once: "Connect Embarko to {your AI tool} once ({link}), then ask me again. After that I can deploy for you directly." **Which route** 1. **connector**: An Embarko connector is in your tools (deploy_app, read_app, update_app, app_danger_zone). Runs outside your sandbox, needs no token, and the app goes straight into the person's account: permanent, nothing to claim. 2. **http_api**: No connector, and you can run commands that reach ship.embarko.ai (for example Claude Code, Codex CLI, Cursor, Gemini CLI with open network). Works today with no setup. The first deploy needs no account; it is temporary until claimed. 3. **connect_first**: No connector, and you cannot reach ship.embarko.ai: a chat app with no terminal (ChatGPT, Gemini, Claude.ai without the connector), or a sandbox that blocks the host. Nothing you do from inside the chat can reach Embarko. Connecting takes the person a minute and fixes it for good. Say: "Connect Embarko to {your AI tool} once ({link}), then ask me again. After that I can deploy for you directly." Find their AI tool on https://embarko.ai/docs/connectors and use that link. If their tool is not listed, there is no connector for it yet: go to route 4. 4. **upload**: Last resort: the person cannot add the connector. Give them the app as a .zip to download. They sign in at https://embarko.ai/app (an account is needed for this route), choose Deploy an app, then Upload file. No terminal needed. The app goes into their account: permanent, nothing to claim. **Does the app fit?** A web app or website, one process, up to 256MB of memory. - WebSockets / live push (Socket.IO, ws): not supported. Instead: Plain HTTP requests, polling from the browser. - Cron jobs and scheduled tasks: not supported. Instead: An HTTP route that does the job, protected by a secret env var, called by an outside scheduler (for example cron-job.org or a GitHub Actions schedule). Tell the person they need to set that up, or set it up with them. - Background workers or several processes: not supported. Instead: Run the work inside the main app, for example right after the request that needs it. Separate apps cannot share files: each has its own DATA_DIR. Only split into two apps when the parts talk over HTTP, like a frontend and a backend (see two-apps). - Managed database or backups: not supported. Instead: SQLite under DATA_DIR. Tell the person it is not backed up. If the app needs one of these, tell the person before you deploy, not after it fails. **What each route accepts** - Connector: deploy_app takes the files themselves: [{ path, content, encoding? }]. Text as-is, binaries as base64. - HTTP multipart: A .tar.gz of the app folder in the "source" form field. Not .zip. - HTTP JSON: The same files list as the connector, as a JSON body. - Upload page: A folder or a .zip (a .tar.gz also works). The browser packs it. Errors and retry rules for every call: see [errors](https://embarko.ai/docs/errors). **Next:** Pick your route, check the app fits, then follow the quickstart. **Related:** [quickstart](https://embarko.ai/docs/quickstart) · [deploy](https://embarko.ai/docs/deploy) --- [Guide home](https://embarko.ai/docs) · JSON: add .json