← ohmyho.stCONTENT HISTORY
WHAT CHANGED
Update to ohmyho.st
Snapshot Nov 4, 2026 · 12:09 UTC · version 0.1.48
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save ohmyho.st and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Build or adapt a TypeScript Vite, TanStack Start, Next.js (including Cache Components) or plain Worker application for ohmyho.st, with managed PostgreSQL, private files, mail, LLMs, images, speech, classifiers and OCR through an OpenAI-compatible gateway, schedules, declared browser origins, egress, video or microphone access. Mail and files use fetch to injected URLs; database access uses its binding; AI calls use the injected endpoint and key from server code. Use for application feature work and source preparation; use the migration Skill for selected Supabase conversion.",
"included_files": [
{
"relative_path": "agents/openai.yaml",
"size_in_bytes": 247
},
{
"relative_path": "references/ai.md",
"size_in_bytes": 10823
},
{
"relative_path": "references/cli-deploy.md",
"size_in_bytes": 57072
},
{
"relative_path": "references/database-runtime.md",
"size_in_bytes": 8206
},
{
"relative_path": "references/mail.md",
"size_in_bytes": 12903
},
{
"relative_path": "references/row-level-security.md",
"size_in_bytes": 7044
},
{
"relative_path": "references/stack-contracts.md",
"size_in_bytes": 45064
}
],
"name": "ohmyhost-build-portable-app",
"skill_md_contents": "---\nname: ohmyhost-build-portable-app\ndescription: Build or adapt a TypeScript Vite, TanStack Start, Next.js (including Cache Components) or plain Worker application for ohmyho.st, with managed PostgreSQL, private files, mail, LLMs, images, speech, classifiers and OCR through an OpenAI-compatible gateway, schedules, declared browser origins, egress, video or microphone access. Mail and files use fetch to injected URLs; database access uses its binding; AI calls use the injected endpoint and key from server code. Use for application feature work and source preparation; use the migration Skill for selected Supabase conversion.\n---\n\n# Build an app for ohmyho.st\n\nPrepare the application's real capabilities, then verify them after deployment.\n\n1. Inspect the selected repository and, with a local checkout, run `ohmyhost init --dry-run --json`. In a native chat, inspect the saved source files and apply the runtime references through the remote file tools; use the actual plan/build diagnostics, without claiming a local command ran. Preserve a valid existing `ohmyhost.yaml`, application root, egress rules, auth choice and migrations. Resolve the returned blockers and requirements rather than replacing the configuration with a reduced file.\n2. Keep one exactly pinned package manager and its matching lockfile. Read `compatibility.frameworks[].status`: `admitted` meets the framework's security floor, `pending` is a version range the build checks after installing it, and `unsupported` blocks until the package is at its `minimum` or a later stable release.\n3. Read [the runtime contracts](references/stack-contracts.md) for the capabilities the app needs. Keep ordinary Astro pages/endpoints, Next.js routes, native TanStack Start server functions, the returned Vite API companion contract, or a plain Worker module (`runtime.mode: functions`, `src/ohmyhost/worker.ts`). The service supplies its build adapter; do not add customer Wrangler/OpenNext configuration merely to host the app. Next.js 16 Cache Components and `\"use cache\"` build here: request-time `\"use cache\"` values are never stored, prerendered values stay until the next deployment, and revalidation is refused, so follow the contracts' Cache Components rules. A `create-next-app` 16.4 app with Tailwind CSS first needs the PostCSS configuration the contracts describe (`next_tailwind_turbopack_only`). Video, audio or microphone need the `_headers` opt-in from the contracts.\n4. For managed Postgres, use the supported application database binding and immutable expand-only migrations. Reach it through `createPrivateDatabaseClient`; use bounded `withConnection` for interactive transactions. Keep network transfers, email and AI calls outside that connection scope. Adding nullable columns without defaults is admitted; DROP, row changes, CREATE OR REPLACE and other changes to existing schema are refused. Preserve production records and read the database Skill for migration limits, sizing, data assignments or reset.\n5. Keep the application's own authentication provider. Better Auth and customer-owned WorkOS are the verified integrations; any other OAuth or OIDC provider is an ordinary application dependency with its own setup and runtime requirements and no completed support claim. Configure actual callback/logout URLs and server secrets, then test login, a protected route, reload and logout. A public app needs no auth provider. Detect actual Supabase capability usage before proposing a migration; an SDK declaration alone does not justify replacing it.\n6. For sending or receiving email, follow [the mail workflow](references/mail.md): choose the customer domain explicitly, prepare and verify a signed application webhook before receiving, and store incoming mail in the customer database. Mail and files use `(request) => fetch(request)` to the injected `*_GATEWAY_URL` values; their origins are allowed automatically and never go in `runtime.egress.allow`. Database access keeps its `OHMYHOST_DATABASE` service binding. Enable only used capabilities. Other server requests to an origin omitted from `runtime.egress.allow` answer HTTP 403 `Egress denied`; browser resources use the separate declared `runtime.browser` policy. Use the current client/runtime libraries and let `init` report missing routes or capabilities. Do not remove a required feature just to obtain a successful build.\n7. For LLMs, images, speech, classifiers or OCR, follow [the AI gateway workflow](references/ai.md): declare `ai.enabled` and a jurisdiction the customer chose, select a compatible orq.ai model from the injected endpoint's `/models`, call it from server code only, and handle credit and gateway failures. Realtime voice has a server-side WebSocket route whose hosted acceptance is still pending; verify it before claiming support in the application.\n8. Run the application's relevant tests, typecheck and framework build through the available execution tools. Prefer focused regressions for the changed behavior and real hosted capability checks; respect the customer's requested verification scope without adding a broad test program. A native chat without test execution must identify that limitation and use actual hosted plan/build results and interaction checks, not invent test success. Use **ohmyhost-deploy** to reuse the saved source, deliver environment secrets privately and verify the hosted app's required reads, writes and integrations.\n\nResolve hosted bindings and trusted configuration from the framework's actual request context. A localhost-only test runtime or a successful health endpoint does not establish production login, tenant setup or background processing. Follow the runtime reference for first-user bootstrap, private uploads and bounded scheduled work when the application needs them.\n\nFor first account setup, use **ohmyhost-get-started**. For publishing, use **ohmyhost-deploy**;\nuse **ohmyhost-deploy-github** only for the selected GitHub source route. [The CLI reference](references/cli-deploy.md) supplies detailed commands when a local checkout is available. For a failed operation, use **ohmyhost-troubleshoot-deployment** and retain its original ID.\n\nReport a suspected hosting bug with `feedback_submit` and a minimal redacted reproduction. Return a working application URL only after its required flows pass. Promotion, rollback and deletion follow the customer's requested scope; an ordinary deploy does not require deleting their app for a cleanup test.\n\n## Astro\n\nUse the [Astro guide](https://docs.ohmyho.st/frameworks/astro). Static uses `astro build`, `runtime.mode: static` and `build.output: dist` without a server adapter. SSR uses the official `@astrojs/cloudflare` adapter, `output: \"server\"`, `runtime.mode: edge`, `build.output: dist/client`, `session: false` and `cloudflare({ imageService: \"passthrough\" })`. Keep the standard `src/` and output directories. The service supplies the deployment config. No native KV sessions, provider cache, Images or customer-defined Cloudflare resources are supported initially. Keep server imports in frontmatter or ordinary modules; put dynamic browser imports in a normal statically imported browser module rather than an Astro template. Verify request-time behavior plus browser islands under hosted CSP. Static build-time filesystem/MDX work remains ordinary Node build work; enable no request-time capabilities on a static plan.\n"
}SHA-256 of public snapshot: edb4515bc4bef43d5b7392a0cb0726277f2ec5483c7e4be1684eaa7a7e2e816e