Limits

What flypod can't do

Last updated: 2026-09-13

flypod is a deploy primitive, not a platform. Every limit below is a decision, made on purpose, because it is what keeps the whole product to one command and one URL. Knowing the edges before you start is worth more than finding them later.

Deploying needs no account. What that does and does not mean — what is screened, on every version, and what gets through anyway — is in Zero-auth is not no-auth.

Static files only

flypod serves the files you upload and nothing else. HTML, CSS, JavaScript that runs in the browser, images, fonts, and Markdown — which flypod renders into pages for you. If a browser can render it, flypod can serve it.

Serving files is a problem with a known-correct answer. That is why a deploy needs no account, no configuration, and no provisioning step: there is nothing to configure because there is nothing to run.

No server code, no databases

There are no functions, no request handlers, no middleware, no scheduled jobs, and nothing stateful behind a site. A deployed site is a set of stored files answering GET requests.

This is the boundary that makes everything else possible. A host that runs your code has to know who you are, meter what you use, and bill you for it — which is where accounts, quotas, and dashboards come from. flypod does not run your code, so it does not need any of that. Your site can still call any API you like from the browser.

If your app needs code running on a server — an API route, a form handler, a session, a queue — flypod is the wrong tool for it, and no amount of configuration will change that.

No build step

flypod deploys the output directory, not the source. It does not install your dependencies and does not run your bundler. Build locally or in CI, then ship the result:

• npx flypod ./dist uploads that directory as-is.
• npx flypod with no argument looks for the first of dist, build, out, .output/public, .vercel/output/static, public, or _site that contains an index.html.

A build that runs on someone else's machine is a build that can fail for reasons you cannot reproduce. flypod takes the artifact you already tested, which is why a deploy finishes in about the time an upload takes.

If you want a push to git to trigger a build you never watch, flypod is the wrong tool for it. flypod has no opinions about your git history and never sees your source.

No custom domains

Every site lives at a flypod subdomain — <site-id>.flypod.page. There is no CNAME setup, no domain verification, and no certificate to wait on, because there is nothing to point anywhere: the URL exists the moment the upload finishes. The site id is 16 hex characters and flypod picks it; there are no chosen names.

Deployed sites are on flypod.page; flypod itself is on flypod.dev. The marketing site you are reading, the docs, the API, the account pages and flypod's email all live on flypod.dev, which never serves uploaded content. Deploying takes no account, so anything anyone uploads is served from a separate domain — reputation damage from a bad upload is then confined to a domain the rest of flypod does not depend on. That is the whole reason for the split, and it applies to every site: claiming a site clears its 14-day expiry, it does not change its address. Site URLs handed out before 14 September 2026 used <site-id>.flypod.dev and redirect to the same id on flypod.page until 13 December 2026.

This is what makes a flypod URL something an agent or a script can produce unattended. A custom domain needs a DNS change, and a DNS change needs a human with access to a registrar — which puts a person back in the middle of the one step flypod exists to remove.

If the URL has to carry your brand, flypod is the wrong tool for it. Ship the production site wherever it already lives and use flypod for the versions of it nobody has agreed to yet.

Every site is public

Anyone with the URL can read a flypod site. There is no password, no allowlist, no signed link, and no private mode. Site IDs are unguessable, and an unguessable URL keeps a site out of the way — it is not a permission.

Access control is the same problem as server code wearing a different hat: to check who you are, flypod would have to know who you are, on every request, which is the account wall the product exists without. Deploy nothing you would mind being read.

If the content is confidential, flypod is the wrong tool for it.

Upload and rate limits

The service ships with the defaults below. They are sized for a built static site, and a site that exceeds them is usually shipping something it did not mean to — an unoptimized video, a node_modules, a stray archive.

• 10 MB for a deploy made in the browser, from this site or the dashboard.
• 50 MB for an uploaded zip, and 100 MB once unpacked.
• 5,000 files per deploy.
• 5 MB for a JSON deploy body, when you post files as JSON rather than a zip.
• 10 deploys per minute per client IP.

Over a size limit the API answers 413 and nothing is stored; over the rate limit it answers 429. The operator may change these limits.

Anonymous deploys last 14 days

A deploy made without an account expires 14 days after it is created. The CLI prints the date and the API returns it as expires_at. After that, garbage collection deletes the files and the site record. The URL stops working. Nothing is archived.

Expiry is the price of asking you for nothing up front. It is also the reason a free anonymous host can exist at all: abandoned content does not accumulate forever, and neither does the cost of storing it. Treat an anonymous deploy as throwaway.

Claiming makes a site permanent

Every anonymous deploy comes back with a claim_token. Sign in and claim the site — from the dashboard or with flypod claim — and its expiry is cleared: the site stays up, at the same URL, until you delete it or delete your account. Deploys made while signed in are permanent from the start and never carry an expiry at all.

Zero-auth is not no-auth

Removing the login removes a blocking step; it does not make flypod a hiding place. Uploads are screened before they are stored, every site is reportable, and a site that is taken down is taken down at the URL.

A free anonymous host on a clean domain is exactly what a phishing operator wants, and pretending otherwise would cost every legitimate site on the domain. Screening is the cost of the front door being open. How reporting and takedowns work.

What you get instead

• A URL in seconds, from a cold start, with nothing installed and no account.
• Versions. Every deploy is a version. flypod update ships a new one to the same site, flypod versions lists them, flypod rollback puts the previous one back.
• Markdown that becomes a site. Deploy .md files and flypod renders them.
• A deploy your agent can finish alone. npx flypod install skill teaches a coding agent the whole loop.
• Nothing to clean up. An anonymous deploy removes itself.

Related: what flypod costs, how abuse is handled and reported, documentation, terms of service, and privacy.