Deploy an app, four ways, one contract

Everything needed to go from a project directory to a live, verified address: set up once, shape the project to the contract, create the app, then ship releases from an AI skill, MCP, the Apps client or plain REST. Addresses, access, environment and rollback follow. For the same tasks step by step, with the web page, see the user manual.

§01Set up once

You need the app.deploy capability on your account (an administrator grants it) and an API token from /tokens.html created with the Apps preset, which can read and deploy apps and read your account profile, and nothing else. The Apps client reads PITCHSTATION_APPS_TOKEN and the MCP server PITCHSTATION_MCP_TOKEN; each falls back to the shared PITCHSTATION_TOKEN. Keep the token in a file only you can read, not in your shell profile. This reads it without showing it:

Then install whichever channels you will use. They share one packager and one API, so mixing them is fine.

The Apps client (terminals, CI, and the MCP deploy tool)

One dependency-free Node file (Node 20 or newer). It packages a directory, deploys, and drives domains, access, env, rollback and readiness.

ps-apps loads the token file for that one command, so the token never sits in every terminal's environment. Every client command in this guide runs through it: the client reads the token only from its environment. Run the box again to update the client, and do so if help shows a clientVersion older than 2026-10-02: older clients have no releases command, no Next.js scaffold and no env_file in the Compose files they generate. The MCP deploy tool uses the copy beside the server, so download that one again too.

The AI skill (Claude Code, Codex and other agents with a shell)

The skill teaches the agent the contract below, when a request is a deploy versus an address change, and to show you every dry run before applying. It drives the Apps client, so install that too.

MCP (assistants without a shell)

Put the MCP server and the Apps client in the same folder: the deploy tool loads the client to package your directory. The MCP server reads PITCHSTATION_MCP_TOKEN, then PITCHSTATION_TOKEN, never PITCHSTATION_APPS_TOKEN. The quick form below puts the token on a command line and stores it in the assistant's settings. --scope user registers the server for every folder; without it, Claude Code offers the tools only in the folder where you ran the command.

To keep the token in your own file instead, add it there once under the MCP server's name, then register a command that loads the file each time the assistant starts the server:

Saving the token again with the first box of this section rewrites the file, so add this line again afterwards. Codex takes the same with codex mcp add. Other MCP hosts take the same command, arguments and env as JSON (use absolute paths). The six app tools are pitchstation_app_list, pitchstation_app_status, pitchstation_app_logs, pitchstation_app_deploy, pitchstation_app_operation and pitchstation_app_readiness.

§02The app contract

Design the app around these five facts. Every one is load-bearing; the troubleshooting table in §08 is mostly what happens when one is missed.

Scaffold

# docker-compose.yml
services:
  web:                                    # ← webService
    build: .
    env_file: .env
    ports:
      - "127.0.0.1:${HOST_PORT:-8000}:8000"  # ← right side = containerPort
    volumes:
      - data:/app/data                    # ← durable state
    restart: unless-stopped
volumes:
  data:

# Dockerfile — non-root, with the volume-ownership fix
FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
# The volume copies this directory's ownership on first mount: create it,
# owned by the app user, BEFORE switching user.
RUN useradd -m app && mkdir -p /app/data && chown -R app:app /app
USER app
EXPOSE 8000
CMD ["python", "-m", "uvicorn", "server:app", "--host", "0.0.0.0", "--port", "8000", "--proxy-headers"]

# .dockerignore — COPY . . must not bake the platform's .env (every secret) into the image.
# Runtime values still reach the container through env_file: .env.
.env

A Vite + React project with package.json, package-lock.json, a build script and index.html needs no Compose file: the packager adds a two-stage build and a static nginx server on port 3000, and stamps an identity marker into index.html that readiness checks for.

App checklist

• Serve static files by allowlist. A catch-all file server will hand /.env or your source to the internet.
• Behind a proxy: trust X-Forwarded-For/-Proto only behind a flag, and mark cookies Secure — TLS ends at the platform.
• Seed the first admin from env (ADMIN_USERNAME/ADMIN_PASSWORD) inside the idempotent migrate hook.
• Add an identity marker such as <meta name="pitchstation-app" content="acme-demo-v1"> and list critical assets, so readiness can prove the address serves this app.
• Smoke-test locally with a fresh project name and volume: build, run the migrate hook twice, start, then check health 200 and that /.env and source paths return 404.

§03Create the app (once)

An app is the permanent record: slug, host, web service, container port, health path, migrate command, budget, access and encrypted env. See the hosts you can use first — your own and the shared ones, with free slots and your quota.

Then create it, private from the first request (recommended) or public. create has no dry run: the app and its address exist as soon as it succeeds. For a private app, make a password file first; it must be readable by you alone.

Where it runs. Give "targetId" to choose a host, or "placement" (region and/or arch) to let the platform choose among your own live hosts and the shared ones. A host must match arch. The region you name is a preference: the platform uses another region when none there has room, and says so. Then it takes the host with the most free budget, tells you why, and lists every host it passed over and the reason. Name arch too when the region matters, and use a region as ps-apps targets shows it. Apps on shared hosts count against your quota (QUOTA_EXCEEDED), a full host answers HOST_FULL, and a budget that does not fit answers RESOURCE_ADMISSION. Budget: "resources": {"memMb": 768, "cpus": 1, "pids": 256} (default 512 MB, 1 CPU, 256 processes); on a shared host it is enforced — the app is killed for memory inside its own budget, never its neighbours'.

The response carries the app id and its permanent hostPort. The address is https://acme-demo.apps.pitchstation.ai on the Oregon host (.apps-ap. on Singapore). Singapore is ARM64: use multi-architecture base images (the official node, python, nginx images are) and no x86-only binaries, or the build fails with exec format error. Creating an app is a write, not a preview. Put secrets in env here or with the env operation in §06, never in the project.

§04Deploy a release

Every channel follows the same rhythm: dry run → review → apply with a key → follow the operation, and for a public app one more step after its first deploy: declare that the app has no access restriction of its own (§05), which readiness requires. The dry run deploys nothing and returns the plan and the exact file list; only an image archive it carries is uploaded and kept (see image archives below). The apply returns an operation ID straight away; the release is live only when that operation reports succeeded. If your connection drops, repeat the identical apply with the same key — it returns the existing operation instead of deploying twice.

With the Apps client

Review the plan, the file list and any Compose warnings, then apply:

--watch polls for up to five minutes; resume any time with ps-apps operation --app 7 --operation OPERATION_ID --watch. Output is JSON, so CI can parse it. On failure the client prints one JSON line with the code, the message and the details the server returned: the fields or Compose settings to fix, the reason, the hosts placement refused, and a correlation id. For a Compose or Next.js project, pass --marker with text your home page's HTML always contains, such as its title; readiness looks for it in the HTML as served, so text that JavaScript draws does not count.

With MCP

Ask in plain language; the assistant calls the tools. A typical exchange:

Behind that: pitchstation_app_list (find the id) → pitchstation_app_deploy with apply:false (the plan, the file list, Compose findings, the budget and packaging warnings) → your confirmation → pitchstation_app_deploy with apply:true and the key → pitchstation_app_operation until succeeded → pitchstation_app_readiness. For a Compose or Next.js project, ask the assistant to pass marker, text the home page's HTML always contains.

With the AI skill

The skill will not create cloud resources, change addresses or deploy anything you did not ask for, and it reports checks it could not run separately from checks that passed.

With REST

Build the archive with the client's packager (it applies the exclusions and limits the server enforces), then post it. First load the token into this one shell: it sets PITCHSTATION_URL and PITCHSTATION_APPS_TOKEN.

It answers { dryRun: true, plan: { liveUrl, steps } }. The token reaches curl on its input (-H @-, curl 7.55 or newer), so it never appears in the list of running commands. Check the plan, then apply:

It answers 202 with { accepted: true, operation: { id, statusUrl } }. Poll the operation until its status is succeeded:

What gets packaged

The client packs the source directory and leaves out:

• VCS and dependency folders: .git, node_modules, venv, .venv;
• build output: .next, .turbo;
• any folder or file named backup or backups, anywhere in the tree;
• credential folders: .aws, .ssh, .codex; and .DS_Store files;
• .env files (templates — .env.example, .env.sample, .env.template, .env.dist — are kept);
• private keys and key files: *.pem, *.key, *.p12, *.pfx, id_rsa, id_ed25519;
• SQLite files (*.db, *.sqlite, *.sqlite3 and their -wal and -shm files), with no warning;
• Postgres or PGlite data folders (PG_VERSION, pg_wal/) and a Redis dump.rdb, with a warning;
• anything listed in a .pitchstationignore at the source root (gitignore syntax: *.log, /fixtures/, docs/**, !docs/keep.md).

Check the dry run's file list. A raw REST upload that carries any of these, apart from the .pitchstationignore entries, is refused, and the error names the path.

Without a Compose file the client scaffolds two kinds of project: Vite + React (npm) and Next.js with output: 'standalone' (npm or pnpm; in a workspace, name the app with --app-dir apps/web). Next.js needs --marker for readiness. A Compose file that is not at the source root is found through the app's composeFile setting (below); relative paths in it resolve from its own directory.

Build elsewhere: image archives

A deploy builds on the app's host, one build at a time, inside the host's build ceiling (40% of its memory by default; a build that runs out fails as BUILD_LIMIT_EXCEEDED with the limit). For a heavy framework build, build on your machine, in CI or on a Devbox, and deploy the images: the host loads them and builds nothing. Every service with build: needs an image: name:tag (use a tag that changes with each release, so a rollback can find older images), and the images must match the host's CPU: each shared host has a fixed architecture, and an isolated host has the one you chose; ps-apps targets shows it, and the dry run refuses a mismatch.

archive runs docker compose build with your local Docker and writes docker save … | gzip; it never overwrites --output, so use a new file name for each build, outside the project. deploy --image-archive uploads it once (the same file is not sent again; images --app 7 lists what the platform keeps: the newest three, up to 1,024 MB each) and deploys with it. By REST: PUT /api/apps/7/images with the raw file, X-Content-SHA256 and Content-Length, then deploy with {"imageArchive": "ARCHIVE_ID"}. With MCP: pitchstation_app_deploy takes image_archive.

On a Devbox (sized for builds), one command builds for the app host's architecture and deploys: python3 ~/.claude/skills/pitchstation-devbox/devbox.py app-deploy box-name --app 7 [--apply], where the pitchstation-devbox skill installs it. It takes the Apps token from the environment or from ~/.pitchstation/.env, where the setup above saved it, and the token reaches the box on the SSH session's input, never on a command line or its disk. With --apply it follows the operation for up to five minutes and prints where it ended.

Migrations, deploy hooks and the Compose file's path

Pre-deploy hooks (up to five) run after the images exist and before the migration; a failure stops the deploy like a failed migration. Post-deploy hooks run after the health check and only warn: the release stays live and the step shows the hook's output. Each hook runs in a new one-off container of its service (docker compose run --rm), where nothing else listens, so a hook calls a script rather than localhost. A rollback runs neither. Settings apply from the next deploy; an operation already accepted keeps the settings it was accepted with. The deploy's dry run (not the settings dry run) refuses a hook or migration in a service the Compose file does not define, unless the file uses include. Commands are never shown back.

§05Addresses and access

Address and access changes are configuration operations: they never rebuild or restart the app. Each is planned against the current configuration version (the ETag), reviewed, then applied with that version and a key. A plan expires after 15 minutes; a stale one is replaced, never forced.

Custom domain

The plan prints its id, its etag and the TXT records. Add them, then verify and apply:

Access and expiry

Access is public or private (a password of 12–72 UTF-8 bytes that you choose and keep). A private app shows people a small sign-in page; the password sets a session cookie for 12 hours, and any password you send ends every session, even when it is the same one again. Scripts and API clients can still send HTTP Basic (user preview). Once a visitor is signed in, their own Authorization header reaches your app, so a bearer-token API works behind the gate. The paths under /__ps/ belong to the gate on a private app. An expiry, with an explicit timezone, closes the app at that moment on every address; it is checked on each request on the host, so it holds even if PitchStation is unreachable. Omit password to keep the current one and its sessions; omit expiresAt to keep the current expiry; send null only to remove it.

The same flows are available by hand at /apps.html: pick the app, edit domains or access, review the plan, apply, then check readiness and copy a redacted receipt.

Access links for one person

An access link opens a private app for one named person without the password: https://<primary>/__ps/enter?t=…. Give it an optional expiry; revoke it on its own at any time, which also ends the sessions it opened. Creating or revoking a link re-applies the app's routing (a few seconds), so the link works once that operation succeeds.

A link gives its person a session of up to 12 hours; opening it again starts a new one.

Public apps: declare the application's own restrictions

The platform controls only its own gate. Whether your application adds a login, an invitation code or its own expiry is something only you know, so every app records an application policy:

The simplest way is at creation: create --public --application-policy none (or "publication": {"access": "public", "applicationPolicy": "none"} in POST /api/apps). For an app created without it, declare none after the first deploy, if it is true, before you run readiness. It is a policy operation — no rebuild, no restart:

The plan prints its id and etag. Apply it, then run readiness:

On the web page it is the Separate application login or expiry selector: choose I confirm the application has no separate restrictions, review the plan and apply. Declaring none for an app that does show a login page does not help: readiness also looks for a password field on the page and fails either way.

Private apps: callbacks, caching, sign-in and link use

• Callback paths — up to five prefixes served without the gate, for signed machine callbacks (payment webhooks, OAuth redirects). Expiry still applies, and your app must verify each callback's signature: these paths are open to anyone who finds them.
• Caching — a private app is no-store by default. Responses your app marks immutable, or that lie under a cachePaths prefix, may stay in the signed-in viewer's own browser cache (private, max-age=31536000, immutable). Revoking someone's access does not remove files already cached on their device, so keep this to content-hashed assets.
• Sign in with PitchStation — listed people, and members of listed teams, open the app with their PitchStation account from its login page; membership is checked at every sign-in. Removing someone takes effect when their session ends (twelve hours at most); removing accounts ends every account session at once.
• Link use — each access link shows how often it was opened and when it was last used, reported by the host every five minutes (link ids and times only).

§06Environment variables

PATCH env previews by default: it lists which keys would change and which stay. Applying needs the configuration ETag and a key, then restarts the current release with the new values (no rebuild). Unrelated keys are preserved. The API never returns values.

That previews the change. Applying restarts the app:

Reserved and refused: PORT, HOST_PORT, COMPOSE_*, DOCKER_*, key names that are not identifiers, and multi-line or NUL values. The older PUT env replaces the whole stored set and does not apply it until the next deploy.

Build-time keys

Frameworks bake public variables into the build (NEXT_PUBLIC_*, VITE_*, REACT_APP_*, NUXT_PUBLIC_*, EXPO_PUBLIC_*, GATSBY_*, PUBLIC_*), so an env change — a restart — cannot apply them. Those keys count as build-time; declare others (or declare one of those runtime) with scopes. Changing a build-time key: the preview lists it under buildScopedKeys with rebuildRequired: true, the change is applied, and the app shows buildStale until the next successful deploy picks the value up. The platform writes the release's .env, with every key, into the release folder before it builds, so the file is part of the default build context (build: .) unless a .dockerignore leaves it out. A framework that reads .env while it builds, as Vite and Next.js do, picks the values up; the client's Vite scaffold, and its Next.js scaffold for an app at the source root, work this way. A Next.js app in a workspace (--app-dir) does not: Next.js reads .env only from the app's own folder. An image-archive deploy is built on your machine with your local env, so the platform's values never reach it, yet the deploy still clears buildStale. Whatever your build copies stays in the image: keep .env out with a .dockerignore unless the build needs build-time keys, and if it does, use a multi-stage build and copy only the build output into the final stage. Do not interpolate them into build:: on shared and strict hosts a ${…} there is refused (COMPOSE_POLICY_VIOLATION, must-be-literal), since guarded settings allow only ${PORT} and ${HOST_PORT}.

§07Operate

The same status, logs, budget and reconcile controls are on /apps.html. When a step fails, its operation shows the redacted tail of that step's own output (build, migration, Compose, health) — values from your environment are masked; TLS and routing steps show only their classification.

Operation states: queued → running → succeeded, or failed / cancelled. waiting_external means a prerequisite outside the platform (usually DNS) is missing. cancel_requested stops at the next safe checkpoint. A cleanup state of reconciliation_required means the remote outcome is uncertain and a blind retry is refused. The operation says who resolves it: reconcile.by: "owner" when only your containers were involved (a migration, up, health) — inspect (this pauses the app's queue of operations while the app keeps serving; the host is read, not changed), check your database, then confirm with a short note; "operator" for routing, certificates, a restore or a quarantined host (a step that timed out or lost its connection) — an admin resolves it from the admin page. Either way the failed operation stays failed; deploy or roll back again to converge.

Rollback recreates a retained release from its Compose file and keeps the current domains, access, budget and last applied env. Every release runs as the same Compose project and the host builds images under the same names, so services the host builds come back at their old code only if each release tags its images differently (for example image: acme-web:2026-10-02-1); images named by tag come back. Without --release it goes to the newest healthy release other than the current one. Normally that is the previous release; after a rollback it is the newer release you rolled back from. Check the dry run's to (a release's releaseTs in releases --app 7), or name the release: releases --app 7 lists the ids. It does not undo database migrations: keep migrations forward-compatible. Deleting an app on your own host removes its registry record only, and keeps its addresses reserved for good (even the same slug cannot be created again); stop it and add ?removeFromHost=1 to clear it from the host and release its addresses. On a shared host the app must be stopped first (APP_RUNNING); deletion then removes its containers, routing and budget from the host and releases its addresses, and keeps its data volumes. A stopped copy left by a recent move must be removed first (§11).

§08Troubleshooting

Every error carries a stable code, whether it is retryable, who must act (publisher or operator) and the next action. The full list is in the API reference.

§09Before you announce it

• The deploy operation reports succeeded — not just accepted.
• For a public app, the application policy is declared none (§05) — otherwise readiness cannot turn green.
• Readiness is green for every hostname: TLS, access policy (anonymous visitors are refused if private), identity marker and critical assets.
• Anything interactive — video, 3D, language switching, payments — was tried in a browser. HTTP readiness cannot certify those.
• If private: the password went to the audience separately, and the expiry is what you meant, with its timezone.

§10Backups and restore

Tell the platform how your app's data is backed up, once. Once it is set up, a deploy of an app that already has a release backs up first: right before its first pre-deploy hook, else its migration, else the start of the new release (unless beforeDeploy is false). Backups also run on demand, and daily if you ask. The host keeps the newest few; the platform keeps the newest 10 away from the host, and they leave the server with the platform's own backups.

The preview shows the exact command the host will run. Save the settings, then back up whenever you like:

To restore, preview first: the dry run says what is replaced.

A failed backup stops the deploy before its hooks, migration and start, and shows the command's output. The running containers are unchanged, but the new build is already on the host: deploy a fix before any env change, which would start it. A restore uses the recipe recorded with the backup, replaces the app's data and needs the dry run's plan.review fingerprint (--review) plus the app's slug as confirmation; if it fails part-way the state is uncertain, and only an operator can reconcile it (§07). You can download the platform's copy of any backup from the Apps page.

Repeat an app for another customer

Create with {"slug":"customer-acme","fromApp":41,"targetId":5,"tags":{"customer":"acme"},"env":{"CUSTOMER_ID":"acme"},"publication":{"access":"private","password":"NEW_PRIVATE_PASSWORD"}}. The template must belong to your account. Only its structural settings are copied; provide fresh environments and private credentials. No data, domains, access links, grants, hooks or releases travel to the new app. Configuration command strings are copied; keep credential values in environment variables.

Upload the image archive once, then deploy the new app with imageArchive:{appId:41,id:"ARCHIVE_SHA256"} and its source/Compose bundle. The server retains a destination archive independently of the source. The source bundle still needs a Compose file whose built services name images contained in the archive.

Check receipt --app NEW_APP_ID for the observed imageDigest and separate archiveDigest. Image evidence is frozen per release; imageEvidenceStatus: "unavailable" and null IDs mean inspection evidence was unavailable. Actual ready time must be measured on your deployment hosts.

Use list --customer acme, or set labels with tags --app NEW_APP_ID --file tags.json containing {"customer":"acme"}. Tags also appear beside each app's spend. An administrator can explicitly assign an operator policy (for example 25 pool apps with 512 MB defaults); the usual quota, host slots and memory limits remain in force until that assignment. No plan pricing is implied.

Private webhook endpoints

Set publicPaths:[{"path":"/api/integrations/pitchstation/webhook","methods":["POST"]}] in a policy plan, then apply it. The Private extras form accepts POST /api/integrations/pitchstation/webhook. Only POST to that exact path skips the gate; expiry still blocks it, and other methods answer 405. The application must validate the signed payload and reject replays. Legacy /prefix/ entries still admit all methods beneath that prefix.

§11Moving to another host

A move copies the release, stops all app services on the current host, takes a final volume backup, builds the release on the destination (a release deployed from an image archive is loaded instead) and restores the data, then routes it there (certificates, access, the DNS record) and proves readiness. Once the move succeeds, the stopped copy stays on the old host for 7 days. The app stays stopped from before the final snapshot until the destination serves, including backup transfer, build and restore.

The dry run shows the destination, the address change, how the data travels and the steps. Then start the move and follow it:

• Data travels through a volume backup (§10), covering all app data. Command backups need a running service and have no supported write-quiescence procedure, so stateful moves using them answer MOVE_UNSUPPORTED; ordinary command backups and restores remain available. An app that keeps nothing moves with --stateless.
• The platform address stays the same between hosts that share a base domain with per-app DNS, and changes when the destination has a different base domain: across regions (for example shop.apps-ap… to shop.apps…), and to an isolated host without per-app DNS, even in the same region (shop.h7.apps-ap…). Two hosts under one base domain answer MOVE_UNSUPPORTED unless per-app DNS is set up. Once the move succeeds, the old address redirects to the new one until the old copy is removed.
• Custom domains stay attached. Lower their DNS TTL beforehand, and point each one at the destination's address (the dry run shows it) as soon as the move has stopped the source: the destination routes the app and issues its certificates only once every name resolves to it, and until then no address serves the app. After 45 minutes the move is recorded as failed after the switch; its routing operation keeps waiting and finishes once DNS resolves. If that operation fails too, roll back to the current release.
• After a platform restart, a move already on the destination is finalized when its routing operation succeeded, or marked failed for recovery there. The app stays on the destination; inspect its routing operation before retrying routing. Failed moves retain their source without automatic removal, and cannot be aborted back to it.
• Moving back within the 7 days replaces the copy the first move left on that host.
• Anything that fails before the switch removes what the destination got and starts the app again where it was.

§12Your own host and spend

Besides the shared hosts, you can reserve an isolated host: a machine nobody else's apps share, in Oregon or Singapore, arm64 or x86, from 2 to 16 GB. The price is all-in (compute, disk and the public IPv4 address) and counts against your monthly cap together with any dev instances; the reservation is refused if it would exceed it. An administrator launches it within a day; once approved it appears in your host list and create can place apps on it. It runs the strict Compose rules and restricted egress (§13) from its first boot. Per-app budgets there are stored and only warn, unless the platform sets APP_RESOURCE_LIMITS=enforce.

Each app is shown its share of its host's monthly price, split by memory budget, and who pays: you on your own host, the platform on a shared one. Release a host you no longer need with hosts --release ID, using the id that hosts lists (not the host id from targets); move or delete its apps first. It acts at once, with no dry run.

Your host reports on itself every 5 minutes (memory, disk, load, containers). Your host list shows the latest numbers, says when a host has stopped reporting, and proposes the next size up when memory or disk has stayed above 85% for half an hour.

§13Strict hosts, egress and acceptable use

• Strict hosts (your own isolated hosts, and shared hosts an admin switches) accept only reviewed Compose keys (on an isolated host the per-app budgets still only warn unless APP_RESOURCE_LIMITS=enforce), keep container names inside your app's namespace, allow no security option but no-new-privileges, send logs only to local drivers, and run every service with no-new-privileges. The dry run names anything refused.
• Exemptions: on an owner's own host, an administrator can grandfather one reviewed finding for one app (for example a port binding that predates the rules), so the host can enforce the rules without refusing that app. Each exemption names the rule and the field, is recorded with its reason, and can expire; a new finding is not covered. Shared hosts never exempt.
• Read-only services: list services that should run with a read-only root file system and a writable /tmp (hardening, or the Apps page). Keep data in named volumes.
• Restricted egress (isolated hosts): containers cannot send mail directly (ports 25, 465, 587), cannot reach the cloud metadata service, and open new outbound connections at a bounded rate. Send mail through an email API over HTTPS.
• Terms: where the platform requires it, accept the publisher terms once, on the Apps page while signed in, before creating apps, deploying live, or quoting or reserving an isolated host. terms shows them; an Apps token cannot accept them (SESSION_REQUIRED).
• Abuse: anyone can report an app at pitchstation.ai/abuse.html. An administrator can take an app down: it stops, every address answers 404, and its owner cannot change it until the takedown is lifted. Who published what, and when, is recorded.