AI prompts

AI assistants give much better answers when they know the platform's actual contract. Each prompt below encodes the relevant Buildfyio behavior — paste it as-is and append your specifics. There's also a machine-readable summary of the platform at buildfyio.com/llms.txt you can attach to any conversation.

Prepare a repo for deployment

I'm deploying this repository to Buildfyio (buildfyio.com), a PaaS that:
- auto-detects frameworks (Next.js, Astro, Vite, Django, Rails, Go, 25+ runtimes) and builds
  with Nixpacks, OR uses a Dockerfile if one exists in the app directory
- builds pnpm/yarn/npm workspace monorepos from the repo ROOT (workspace:* deps work)
- installs devDependencies at build time; runs "prisma generate" when a schema exists
- requires the app to listen on 0.0.0.0; if the start command has an explicit port
  (e.g. "next start --port 3002") the platform follows it
- runs containers as a non-root user (write only to /tmp outside the app dir)
- provides env vars at build time AND runtime (secrets never enter image layers)

Review the repo and tell me:
1. Anything that would break under these rules (localhost binds, root-only writes,
   undeclared dependencies, missing engines.node)
2. The correct build command, start command, and port I should expect detection to find
3. The env vars this app needs, split into secret vs public

Debug a failed build

My Buildfyio deployment failed. Below are the diagnosis card and the build log tail.
Platform facts you should assume:
- builds run from the repo root for workspace monorepos, with root+app node_modules/.bin on PATH
- devDependencies ARE installed during the build
- a strict lockfile install is attempted first, then a plain install
- "Cannot find module X" usually means an undeclared dependency in THIS app's package.json
- containers are killed if nothing listens on the detected port (web apps only;
  worker-type apps have no port checks)

Diagnosis card: <paste>
Build log tail: <paste>

Tell me the single most likely root cause and the exact change to make in the repo.

Set up a monorepo

Restructure/verify this repo as a workspace monorepo that deploys cleanly to Buildfyio:
- root package.json with "workspaces": ["apps/*", "packages/*"] (or pnpm-workspace.yaml)
- ONE committed root lockfile for the package manager we actually use
- each deployable app under apps/<name> with its own package.json, build and start scripts
- every import an app uses declared in that app's own package.json (no phantom deps)
- shared code in packages/* referenced via workspace:* versions
On Buildfyio each app becomes an independent deploy with its own subdomain
(<project>-<app>.buildfyio.com), env scope, and custom domains.

Add a background worker

Add a queue worker to this app for deployment on Buildfyio:
- a long-running script started by "npm run worker" (no HTTP server needed — Buildfyio
  worker-type apps get no port health checks; the process just has to stay alive)
- it must exit non-zero on fatal errors (the platform restarts it)
- read config from process.env (shared project env vars reach the worker automatically)
- log to stdout/stderr (streamed in the Buildfyio dashboard)
Then tell me: the polling/queue pattern you chose and any env vars I must add.

Migrate from Vercel

Help me move this app from Vercel to Buildfyio. Facts:
- push-to-deploy from GitHub works the same (production branch → auto deploy)
- env vars: paste the .env into Buildfyio's env import; NEXT_PUBLIC_*/VITE_* stay public,
  everything sensitive is auto-treated as a secret
- Astro repos using @astrojs/vercel deploy UNCHANGED (the platform swaps in a node
  adapter at build time); next.config needs no output changes
- vercel.json redirects/rewrites/headers are honored at deploy time
- custom domains: CNAME to cname.buildfyio.com (subdomains) or A record for the apex;
  on Cloudflare use grey-cloud during verification
List everything in this repo that is Vercel-specific and what (if anything) to change.

Write a Dockerfile for full control

Write a production Dockerfile for this app to run on Buildfyio:
- final process must listen on 0.0.0.0:$PORT (PORT env is provided)
- must run as a non-root user; writable paths are /tmp only
- multi-stage: deps → build → slim runtime
- do NOT bake secrets into layers; they arrive as env at runtime
Place it at the app's root directory — Buildfyio uses it verbatim when present.

Set up the CLI

Help me ship this project with the Buildfyio CLI.

Install and auth:
  npm i -g @fyio/buildfyio-cli   # binary: buildfy
  buildfy login
  buildfy link                   # link this directory to a project

Deploy and observe:
  buildfy deploy                 # production deploy of the current branch
  buildfy deploy --preview       # preview deploy
  buildfy deploy --branch <name>
  buildfy logs                             # latest deployment (build stream)
  buildfy logs <deploymentId> --stream deploy|runtime|build

Environment variables:
  buildfy env pull --env production --file .env.local
  buildfy env pull --no-secrets
  buildfy env push --env production --file .env.local

Review the repo first, then tell me the exact command order for MY setup and
whether any required env var is missing before the first deploy.

Connect an AI agent (MCP)

Connect Buildfyio to my agent over MCP.

Easiest path (the CLI writes the client config and mints a scoped token):
  buildfy mcp install claude-code      # or claude-desktop | cursor | windsurf
  buildfy mcp install cursor --scopes read,deploy

Manual config:
{
  "mcpServers": {
    "buildfyio": {
      "command": "npx",
      "args": ["-y", "@fyio/buildfyio-mcp"],
      "env": {
        "BUILDFYIO_TOKEN": "<Dashboard → Settings → API tokens>",
        "BUILDFYIO_ORG": "<org id or slug>"
      }
    }
  }
}

Tools exposed: list_projects, create_project, deploy, get_deployment_status,
get_logs, set_env_var, rollback, get_build_failure.
Destructive tools need the write scope AND confirm:true.

Verify the setup by calling list_projects.

Daily operations with the agent

The Buildfyio MCP server is connected. Do this:

1. list_projects — show my projects.
2. get_deployment_status for the latest deployment of <project>.
3. If it failed, call get_build_failure (structured root cause + fix, not raw
   logs) and summarise the cause in one sentence.
4. If the fix belongs in my code, propose the exact change. If it is a platform
   problem, say so. Do NOT roll back without asking me first.

Use get_logs (stream: build | deploy | runtime) only when you need raw output.

Use the SDK from code

I want to drive Buildfyio programmatically with @fyio/buildfyio-sdk.

  npm i @fyio/buildfyio-sdk

  import { Buildfyio } from '@fyio/buildfyio-sdk';
  const client = new Buildfyio({ token: process.env.BUILDFYIO_TOKEN! });
  // default API: https://api.buildfyio.com (override with baseUrl)

Token: Dashboard → Settings → API tokens (scopes: read / deploy / write).
Failures throw HttpError with the status and body attached.

Write me a script that: <what you need>. Read the token from the environment,
never hard-code it, and print actionable errors.