---
name: anyhost
description: "Operate Anyhost from an external user's application repository. Use for Anyhost CLI setup or updates, GitHub repository linking, environment configuration, secrets, managed Postgres/Redis/storage/email, deployments and production readiness, status/log/health incidents, custom domains/DNS/certificates, and ownership/export/handoff work."
---

# Anyhost

Use this skill in the user's application repository, not to develop the Anyhost product itself.

## Route The Task

Read only the references needed:

- CLI install, authentication, linking, or skill refresh: `references/cli.md`
- Workspace, project, environment, deployment, resource, or permission state: `references/context.md`
- Runtime config, secrets, Postgres, Redis, or object storage: `references/managed-services.md`
- Transactional email resources, sender DNS, runtime send capability, or templates: `references/email.md`
- Model API Resource lifecycle, budget, status, or deployment injection: `references/managed-services.md`; for application model calls, model selection, streaming, tools, errors, or usage settlement, route to `../anyhost-model-api/SKILL.md`
- Dev/prod deployment, production readiness, migration, rollback, or verification: `references/deploy.md`
- Custom domains, DNS, certificates, apex handling, or cutover: `references/domains.md`
- Status, logs, health, runtime debugging, or incidents: `references/ops-context.md`
- Ownership, migration away, export, or handoff: `references/export-portability.md`
- Migration of an existing project or provider-backed capability across
  hosting, data, storage, authentication, DNS, callbacks, or source retirement:
  `../project-migration/SKILL.md`; return here for Anyhost-specific CLI and
  control-plane operations. Do not use it for routine creation of a new Anyhost
  resource with no existing capability to preserve or retire.

For read-only questions, inspect and report; do not commit, push, configure resources, or deploy. Enter a deployment workflow only when the user asks to deploy or a requested implementation must be deployed to complete the task.

## Work From Current State

1. Inspect the repository and preserve existing user changes.
2. If the task needs Anyhost state, verify the CLI, authenticate/link when necessary, run `anyhost context`, and read `.anyhost/context.json`.
3. Confirm the intended workspace, project, repository, and environment before acting.
4. Perform only the requested configuration, resource, domain, or deployment work.
5. Refresh state and verify the observable result before reporting completion.

## Safety Boundaries

- Treat `.anyhost/context.json` as the authority for Anyhost state; do not invent resources, credentials, URLs, or deployment status.
- Use the CLI for Anyhost control-plane operations. For Email, integrate the application only through the documented five-variable runtime contract in `references/email.md`; context metadata without those generated variables is not sufficient runtime authentication.
- Never commit `.anyhost/`, `.agents/`, `.env`, tokens, raw secrets, connection strings, or provider credentials.
- Require explicit user confirmation immediately before any production mutation, production secret reveal, production resource operation, production email-template publish, destructive operation, or production deploy.
- Canonical CLI commands do not use a generic `--yes` flag. Obtain user
  authorization for production or destructive work, then use the command's
  explicit target, typed confirmation, or reviewed plan ID.
- Do not call AWS, Cloudflare, or another provider directly unless the user explicitly requests provider-level work.
- Keep provider machinery secondary. Lead with environment, status, URL, health, resources, evidence, and risk.

## Completion

Report the target environment, actions taken, deployment/resource status, public and logs URLs when available, verification performed, skipped checks, remaining risks, and whether further confirmation is required.