Technical

First, open the build's status page — every stage has a Logs button that shows exactly where it failed. Most failures fall into three buckets: a transient infrastructure hiccup (just click Retry), a code error the AI can fix on its own (start a chat with "the build failed, the error is: …" and paste the relevant log line), or an upstream issue with a connected service (Stripe, GitHub, your custom domain provider). If none of those apply, message support with the project ID — we can re-run the pipeline manually.

Three common causes. (1) The DNS hasn't fully propagated yet — wait 5–15 minutes and hard-refresh. (2) Your browser cached an older asset — open in an incognito window. (3) The first build's output was syntactically valid but logically wrong — start a chat with "the page is blank when I open the home page" and the AI will fix it on the next refinement. The browser console (F12 → Console tab) usually shows the underlying error.

Builds run in a shared queue. Free and Starter plans have standard priority and may wait a few minutes during peak hours; Pro and Business get priority slots and almost never queue. If your build has been queued for more than 10 minutes, that's unusual — refresh the page (the status updates over websocket and sometimes the connection drops), and if it still hasn't started, message support with the project ID.

Yes. Open the project, click the three-dot menu, and choose "Redeploy". Your code stays exactly the same — but new environment variables get picked up, expired build artifacts get rebuilt, and any platform-side improvements (security patches in the runtime, for example) are applied. A no-change redeploy costs 1 credit and finishes in under a minute.

On AWS, in the us-east-1 region by default. Static assets serve from CloudFront's global edge network, so your visitors hit a nearby PoP regardless of where the origin lives. Server-side rendering runs on AWS Lambda, your project's database is on Amazon RDS Postgres, and uploaded files live in S3. EU data residency is on the roadmap but not yet available — let support know if it is a hard requirement for you.

Yes — your project's code lives in a GitHub repo we created in your name. Open the project's Settings → Repository to see the URL and grant your account write access. Clone, fork, or move it to another GitHub org as you would with any repo. The same goes for your database (we expose a Postgres connection string under Settings → Database → Export). You keep ownership of the code and the data; FloopFloop is a deployment + AI layer on top.

On Pro or higher: open the project, go to Settings → Domains, click "Add domain", and enter your domain (root or subdomain). FloopFloop shows two DNS records to add at your registrar — a CNAME (or A/ALIAS for an apex domain) and a TXT record for verification. Once both are detected, SSL provisions automatically and the domain goes live, usually in 5–30 minutes. Free and Starter plans don't support custom domains; upgrade to use this.

Most issues are DNS-side. Check that the CNAME (or A/ALIAS) record exists, points to the value FloopFloop showed you, and is not behind a proxy that blocks our verification (Cloudflare "orange cloud" needs to be off until verification finishes — flip it back on after). Use `dig your-domain.com +short` from a terminal to verify what the world sees. Verification usually takes under 15 minutes; if it's been an hour and the dashboard still shows "Pending", message support with the domain.

All secrets are encrypted at rest with AES-256 in AWS Secrets Manager and only decrypted at request time inside your project's runtime — they're never written to disk or build logs. Once you save a secret, the value is write-only: you can update or delete it but never read it back from the dashboard. FloopFloop staff don't have access to plaintext values; what we see is the key name and the audit metadata.

Yes. Open Settings → Secrets, find the entry, click "Rotate", and paste the new value. Within ~30 seconds the running runtime starts reading the new value (we hot-reload secrets and don't restart the function). If the secret is part of a build-time config (rare), you'll see a banner asking you to redeploy — that takes about a minute and costs 1 credit.

Tell the AI in chat: "add a cron job that runs every day at 9 AM and emails me a summary of new sign-ups". The AI generates a `/api/cron/<name>` route in your code, registers the schedule (cron expression or interval), and on every redeploy our scheduler keeps the registration in sync. Each invocation arrives with a project-scoped bearer token so only our scheduler can trigger it. View runs and logs under Settings → Schedules.

On macOS and Linux: `curl -fsSL https://floop.tech/install.sh | sh`. On Windows: download the latest installer from the GitHub Releases page of the floop-cli repo, or use `winget install FloopFloopAI.floop`. Once installed, run `floop login` — that opens a browser to authorise this device. From there, `floop new`, `floop refine`, `floop deploy` and the rest of the commands work without further setup.

A CLI token is the credential `floop login` writes to your local config — it identifies the human user on a specific device, and you can revoke it from /account/devices when you stop using a laptop. An API key is for unattended access from scripts, CI, or third-party apps — you create them under /account/api-keys, scope them per project if you want, and rotate them whenever. Both call the same `/api/v1/*` surface, but only API keys should be checked into automation.

Yes — the eight first-party SDKs (Node, Python, Go, Rust, Ruby, PHP, Swift, Kotlin) all wrap the same `/api/v1/*` surface and ship matching method names. When we add an endpoint, we mirror it across every SDK in the same release. The MCP server (`@floopfloop/mcp`) re-exposes the Node SDK to LLM agents and gets the new method automatically. If you spot a gap, it's a bug — open an issue on the relevant SDK repo.