Put an app online

Something that runs code — Node, Python or PHP. What your agent sends, what we build, and how to confirm it actually serves.

An app is anything that needs code running to answer a request: an API, a form that does something, a dashboard, a webhook receiver, a small tool.

Ask for it

put this app online

Your agent picks the runtime from your files and sends them. About a minute later you have a link with HTTPS on it.

If your app needs an API key or any other secret, say so in the same breath. Environment variables are set when the app is created and can't be changed afterwards, so it saves a rebuild to get them in the first time:

put it online, and set OPENAI_API_KEY to the one in my .env

What each runtime expects

Your agent handles this. It's here so you can check its work when a build won't come up.

Runtime	Your project must have	How it starts
Node	`package.json` with a `start` script	`npm start`
Python	`app.py` exposing a WSGI callable named `app`, and `gunicorn` in `requirements.txt`	`gunicorn app:app`
PHP	`index.php` at the project root	Apache serves the root; `index.php` is the front controller

These are conventions, not settings

There is no start-command field and no port field. If a build starts and then dies, it is almost always because the entrypoint isn't where the runtime looks for it. That is the single most common failure here — see Common pitfalls.

A minimal example of each

Node — package.json

{
  "name": "my-app",
  "scripts": {
    "start": "node server.js"
  }
}

Python — app.py

from flask import Flask

app = Flask(__name__)          # the name `app`, in the file `app.py`

@app.route("/health")
def health():
    return {"ok": True}

Python — requirements.txt

flask
gunicorn

PHP — index.php

<?php
echo "hello";

Confirm it actually serves

Ask your agent to open the link, not just to report success:

open the URL and tell me what it returns

A build can be queued, report as running, and still be crash-looping. A real HTTP response is the pass condition. If it isn't serving, Fix a broken deploy walks through it.

Adding a /health route that returns something trivial makes this check unambiguous, and costs you three lines.

Secrets and configuration

API keys, passwords and anything else your app needs at run time go in as environment variables. They're stored apart from your code and never written into your source.

You set them yourself, in a browser — your agent has no way to. Ask it to manage your environment variables and it hands back a link to /secrets-manager; sign in there with an emailed code and type them in. Change or rotate them whenever you like: saving restarts the app with the new values. Your agent only ever sees the names. See Environment variables.

Under the hood

We generate a Dockerfile for your runtime and build it:

Node — a multi-stage build on node:<version>-slim. npm ci (falling back to npm install), then npm run build --if-present, then npm start in a slim production image with NODE_ENV=production.
Python — python:<version>-slim, pip install -r requirements.txt, then gunicorn app:app bound to the container port.
PHP — php:<version>-apache serving the project root. If a composer.json is present, Composer installs your dependencies with --no-dev --optimize-autoloader.

Build output you ship is ignored: node_modules, vendor, .venv, __pycache__, .git and .env files are excluded from the build context. Send your source, not your dependencies.

A committed Dockerfile is ignored

agenthost always builds from its own generated recipe. A Dockerfile at your project root is stripped before the build and never takes it over. When the runtime conventions don't fit, commit an agenthost.yaml to set the install, build and start commands — that is the supported way to customize a build. Anything beyond it — a Go binary, a worker with system dependencies — isn't supported here.

Runtimes in full

What each runtime detects on, builds and runs.

Choosing a version

Pin Node 24 or Python 3.13 instead of the default.