Push to a connected branch
You connect a GitHub repo + branch once via the Builder. From then on, every push to that branch triggers a deploy. The webhook that GitHub posts is HMAC-signed with a secret only Turtini knows.
Integration · Pull-to-Host
Connect a repo + branch. Every push pulls fresh files via the Trees API, runs a vulnerability scan, and deploys to Cloudflare-fronted GCS — under your custom domain or a preview URL. Static-only V1, secure by default, no build commands ever run on our infra.
What happens on push
You connect a GitHub repo + branch once via the Builder. From then on, every push to that branch triggers a deploy. The webhook that GitHub posts is HMAC-signed with a secret only Turtini knows.
Turtini reads the changed tree using the GitHub Trees API in a single round-trip — 50 files or 500, it's the same number of requests. We never run npm install or any code from your repo on our infra. Static files only.
Every uploaded file is scanned for committed credentials before it's allowed to deploy. Critical findings (live AWS / Stripe / GitHub / OpenAI / Anthropic / Google credentials, PEM private keys) block the deploy entirely. Warnings (eval, hardcoded passwords, leaked JWTs) surface in the deploy log without blocking.
Cleared files land in a Google Cloud Storage bucket under hosted-sites/{siteId}/. A Cloudflare Worker maps your hostname → bucket prefix at request time, so adding a custom domain is a Cloudflare DNS row plus a single config write — no Turtini deploy needed.
Every deploy lands a row in the integrationEvents log: commit SHA, branch, scan results, files written, time-to-publish. The connected-site panel in your Builder shows green / failed / scanning at a glance.
Who it's for
Vibe-coders graduating from Lovable / Bolt / v0
You shipped a prototype on a no-code AI builder. Now you want a real domain, real auth, real CRM behind it. Push your AI-generated code to GitHub, connect it here, and Turtini hosts it under your domain — alongside your real Turtini modules.
Read about graduation pathsStatic-site devs (Astro, 11ty, Hugo, Vite)
Your build already runs in CI. Connect Turtini to the branch that holds the built output (or let our GitHub Action bootstrap one). Get a Cloudflare-served custom domain, preview URLs per branch, and zero-config TLS.
See the GitHub Action bootstrapBuilder-site authors who want to own the source
Use Turtini's drag-and-drop Builder, then export to GitHub. The exported repo is real source you can hand to a developer or keep editing in the Builder — the export round-trips cleanly.
Open BuilderThe whole setup
# 1. In Turtini, open Settings → Integrations → GitHub # Authorize Turtini against your GitHub account. # 2. In your Builder site (or a fresh one), open the # Connected Hosting panel → "Connect repo" → pick the repo + # branch you want to deploy from. Turtini installs a webhook # on the repo automatically. # 3. From now on: git push origin main # → GitHub fires the webhook # → Turtini pulls the changed tree # → Vulnerability scan # → Files land in GCS # → Cloudflare serves your domain # → Done # 4. (Optional) Need a build step? Click "Bootstrap GitHub Action" # in the same panel — Turtini opens a PR adding # .github/workflows/turtini-deploy.yml that runs your build in # CI and pushes the output to a branch we watch.
FAQ
No — by design. Running arbitrary build commands inside our infra would expose us (and you) to postinstall scripts and supply-chain attacks. Instead, we auto-bootstrap a GitHub Action workflow that builds in your CI and pushes the output to a branch we watch. Free, secure, standard practice. The bootstrap PR adds .github/workflows/turtini-deploy.yml on demand.
Push to any branch that's not your connected primary, and Turtini deploys it to <branch>--<siteId>.preview.turtini.com. They auto-clean after 14 days of inactivity. Your production domain only ever serves the connected primary branch — no chance of leaking a draft.
A pure-JS regex pass over every file before upload. Critical (block): committed AWS keys (AKIA…), Stripe live secrets (sk_live_…), GitHub personal access tokens (ghp_…, github_pat_…), OpenAI / Anthropic / Google service-account credentials, and PEM private keys (-----BEGIN PRIVATE KEY-----). Warnings (don't block, but logged): eval() calls, password = "literal" assignments, JWTs in source. We skip example/sample/test paths so fixture data doesn't set off the alarm.
Two options. (1) Run your build in CI (GitHub Actions, CircleCI, anything) and commit the built output to a branch — connect that branch to Turtini. The auto-bootstrapped GitHub Action does this for you for npm-build sites. (2) Custom-build sandbox is on the V2 roadmap — sandboxed Cloud Run runners with strict network egress controls. If you'd benefit, get in touch.
Yes — Turtini integrates with Cloudflare for managed domains. Point your apex / subdomain at us, we provision the TLS cert (via Cloudflare's edge), and your hostname starts serving the connected branch within minutes.
Disconnecting deletes the GitHub webhook on your repo, drops the hostedSites doc, and (optionally, if you tick the box) purges the GCS folder for the site. Your repo stays untouched. Re-connecting later starts fresh.
Yes — the connected-site panel has a "Deploy now" button that triggers a fresh Trees-API pull from the connected branch. Useful for testing or recovering from a webhook miss.
50 MiB per deploy bundle, up to 500 files. If you're bumping that ceiling you're likely shipping un-optimized images — open an issue and we'll work with you.
Turtini uses cookies to improve your experience, analyze site traffic, and personalize content. By clicking Accept, you consent to our use of cookies. Privacy Policy
Wally
Your Turtini assistant
Hi, I'm Wally!
Ask me anything about Turtini — features, pricing, how things work, and more.
Already have an account? Sign in
Wally can make mistakes — verify important info.