Common questions about GitFly
What GitFly is, what it supports, how the deploy mechanism works, and how the AI agent generates configurations.
What is GitFly?
GitFly is a web service that turns any public GitHub repository into a live, running preview by changing one part of the URL. Users replace github.com with gitfly.ai in a repository link, and the platform fetches the repository, has an autonomous AI agent detect the project type, generates the deploy configuration, and starts an ephemeral preview machine on Fly.io. There is no cloning step, no local install, no manual deploy configuration, and no account or signup. GitFly is built for developers who want to try a project before cloning it, share working previews of pull requests, and demonstrate repositories without asking viewers to set up a local environment. The platform supports more than sixty frameworks across eleven language ecosystems, including frontend single-page apps, full-stack frameworks, backend APIs, Chrome extensions, Jupyter notebooks, Python scripts, Flutter web, Unity WebGL, and multi-service monorepos.
How does GitFly deploy a repository?
When a visitor opens a gitfly.ai URL, GitFly fetches the public repository and an autonomous AI agent reads its contents to identify the project type, language ecosystem, and required runtime. The agent runs a pre-build validation pass against a capabilities manifest, then emits a Dockerfile and framework-specific build configuration. The build is performed by the Fly remote builder, and on success the resulting image is launched as an ephemeral Fly.io machine that serves the preview. The AI provider is XAI grok-4-1-fast-non-reasoning, used for detection, configuration synthesis, and structural retries. If a build fails, the platform performs up to three self-healing attempts that re-analyze the build logs, patch source files where appropriate, and retry. Build sessions are idempotent, so a refresh during an in-progress build resumes the existing run rather than starting a new one.
Which frameworks does GitFly support?
GitFly supports 60+ frameworks across eleven language ecosystems: Node.js, Python, Go, Rust, Java, Ruby, PHP, .NET and C#, Elixir and Phoenix, Deno, and Bun. On the JavaScript and TypeScript side, the platform handles Next.js, Remix, NestJS, AdonisJS, SolidStart, Qwik City, VitePress, Docusaurus, and Eleventy, plus React, Vue, Svelte, and Angular single-page apps. Python coverage includes FastAPI, Flask, Django, Sanic, Litestar, Tornado, Streamlit, Gradio, Solara, Dash, Panel, MkDocs, and Sphinx. JVM support spans Spring Boot, Quarkus, Micronaut, Helidon, Vert.x, Ktor, and Javalin. Ruby covers Rails, Sinatra, Hanami, Roda, Bridgetown, and Middleman. PHP includes Laravel and Symfony, and the .NET ecosystem covers ASP.NET Core, Blazor Server, and Blazor WebAssembly. Phoenix and Phoenix LiveView are supported on Elixir. Beyond traditional web apps, GitFly also handles Chrome extensions, Jupyter notebooks, Python scripts, Flutter web, Unity WebGL, and multi-service monorepos.
How much does GitFly cost?
GitFly is free for both public and private GitHub repositories. The platform absorbs the compute and infrastructure costs of running ephemeral previews on Fly.io, so you do not pay per build, per minute, or per machine. There is no credit card requirement, no usage meter, no trial period, and no paid upgrade path. The free tier is the only tier; there is no paid plan, no team plan, and no enterprise plan. Public repositories deploy with no account at all: open a gitfly.ai URL and the preview runs. Private repositories require signing in with GitHub so GitFly can access the repositories you choose, but they cost nothing to deploy. Because the model is built around ephemeral previews, there is no per-seat billing and no storage subscription. The trade-off is that previews tear down after a period of inactivity rather than persisting indefinitely, which keeps the cost of running GitFly predictable and bounded.
What is the lifecycle of a GitFly preview?
A GitFly preview spins up the first time someone opens its URL. The platform fetches the repository, generates the deploy configuration, builds the image on the Fly remote builder, and launches an ephemeral machine on Fly.io. Once running, the preview stays warm for visitors and auto-stops after a short idle window, then wakes again on the next request. After roughly 24 hours of inactivity the underlying infrastructure is torn down and the preview is destroyed; reopening the URL afterward triggers a fresh build. Build sessions are idempotent, so refreshing the page or revisiting during a build resumes the existing run instead of starting a new one. Failed-but-live previews remain tracked rather than orphaned, so the lifecycle layer can wake stopped machines, cascade retries, and clean up on schedule without losing authority over a deployment.
Does GitFly support private GitHub repositories?
Yes. GitFly supports both public and private GitHub repositories. Public repositories still deploy with no login at all: replace github.com with gitfly.ai in the URL and the preview runs, exactly as before, with no account, no signup, and no credentials. To deploy a private repository, sign in with GitHub and install the GitFly GitHub App on the specific repositories you choose. GitFly can only see the repositories you grant to its GitHub App, never your whole account. Once private access is enabled, you can search your accessible repositories and deploy them by default branch, branch, or commit, the same way public repositories work. Private deployments are owned by your authenticated GitHub account, and the previews they produce are unlisted rather than fully access-controlled. GitLab and Bitbucket are still not supported. You can disconnect GitFly from your account at any time to stop all private repository listing and deployment.
How does GitFly compare to Vercel, Netlify, or Replit?
Vercel and Netlify are hosting platforms; they require a user account, an explicit repository connection, and a configuration commit before they can deploy a project. Replit is a workspace-first product where users open an editor session to run code in the browser. GitFly takes a different shape: it is zero-configuration and ephemeral by design. There is no account, no repository connection step, no configuration commit, and no workspace; visitors simply replace github.com with gitfly.ai in any public repository URL and the preview runs. Framework support is also broader, with 60+ frameworks across eleven language ecosystems, including Java, Rust, .NET, Elixir, Bun, Deno, Flutter web, and Unity WebGL, alongside the JavaScript and Python frameworks the hosting platforms cover. The intended use case is ephemeral preview rather than long-lived hosting: pull-request reviews, repository demos, and exploratory clicks before cloning.
Does GitFly support backend-only or API repositories?
Yes. Backend-only repositories that expose an HTTP API receive a full Postman-like API explorer rendered directly in the browser, so visitors can interact with the deployed service without needing a separate REST client. The explorer surfaces detected routes, request and response shapes, and authentication headers, and it includes AI-generated request suggestions that let users invoke endpoints with sensible defaults. GitFly handles backend frameworks across multiple ecosystems: Express, Fastify, NestJS, and AdonisJS on Node.js; FastAPI, Flask, Django, Sanic, Litestar, and Tornado on Python; Spring Boot, Quarkus, Micronaut, Helidon, Vert.x, Ktor, and Javalin on the JVM; Rails, Sinatra, Hanami, and Roda on Ruby; Laravel and Symfony on PHP; ASP.NET Core on .NET; and Phoenix on Elixir, plus Go and Rust HTTP services. The same ephemeral Fly.io machine that runs a frontend preview runs the backend service for the explorer.
How does GitFly handle trust and security?
Each GitFly preview runs inside an isolated Fly.io ephemeral machine with no persistent state, so a build or runtime failure cannot reach across to other previews. Public repositories opened through a gitfly.ai URL need no credentials at all. For private repositories, GitFly stores the GitHub tokens it needs to clone your code; those tokens are encrypted at rest on the server and never appear in cookies, browser storage, URLs, build logs, or client responses. Clone credentials are resolved only inside the worker, used only by the clone step, and scrubbed before analysis and build run. GitFly can only access the repositories you grant to its GitHub App, and access is revalidated before every private deployment. Sensitive surfaces such as environment variables, logs, retry endpoints, and terminals are gated by deployment identity, not by repository path. The AI tools that read and patch code operate inside canonical filesystem sandboxes to prevent path-escape and traversal.
How does GitFly's AI generate the deploy configuration?
GitFly uses an autonomous agent built on XAI grok-4-1-fast-non-reasoning. The agent reads the repository contents, identifies language and framework signals from manifest files and source layout, and runs a pre-build validation pass that checks the project against a capabilities manifest of known-good build patterns. From that analysis it emits a Dockerfile and a framework-specific runtime configuration covering install, build, and start commands. If the initial build fails, the platform runs up to three self-healing attempts. Each attempt re-analyzes the build logs against the prior context, patches source files where appropriate (lockfiles, missing dependencies, framework-specific configuration), and retries. Code-level patches are produced by a reasoning variant of the model for higher-confidence edits, while structural retries continue to use the non-reasoning model. The full agent loop tracks calls against a 256K-token session budget to prevent runaway retries.
How do I disconnect GitHub from GitFly, and what happens to my access?
You stay in control of GitFly access at all times. Signing out of GitFly ends your session but leaves your GitHub authorization in place, so you can sign back in without re-approving anything. Disconnecting GitHub is the stronger action: from the account menu, GitFly revokes and deletes the GitHub access it stored, and private repository listing and deployment stop immediately until you reconnect. You can also revoke access directly from GitHub by uninstalling or editing the GitFly GitHub App. If a token is revoked, expires, or loses repository access, GitFly detects this on the next check and shows reconnect guidance rather than failing silently. Reconnecting is simply signing in with GitHub again, which restores access on a fresh grant. Public repositories opened through a gitfly.ai URL never depend on any of this and keep working with no login. Existing private deployments are owned by your account and follow the same access rules after you reconnect.
Are GitFly previews of my private repository private?
Private previews on GitFly are unlisted, not fully access-controlled. When GitFly deploys a private repository, the resulting preview carries an honest label that reads: Unlisted preview, anyone with this link can view the running app; it is not access-controlled. This means the preview URL is not advertised or indexed, but anyone who has the link can open the running app, so GitFly does not claim the preview itself is private or gated. Treat a private preview link the way you would treat a secret: share it only with people you trust, and let the preview idle out when you are finished. Public repositories deployed from a gitfly.ai URL carry no such caveat because the underlying repository is already public. A fully authenticated preview gateway is planned for the future but is not part of how GitFly previews work today, which is why the unlisted disclosure is shown verbatim on every private preview surface.