Connect GitHub

Connect GitHub and your project gets a source of truth: every change an agent makes is committed to a repository you own, so you always have the code — readable, diffable, and portable — independent of Typillar.

Optional, but it’s where your history lives

GitHub is not required to build. Cloudflare is the only connection Typillar insists on; the GitHub step in onboarding carries a Skip for now, and you can connect it later from Settings → Connections.

Skipping has one concrete cost, and it’s worth knowing before you skip: the repository is the version store. Until GitHub is connected, a project has no version history — the Versions list is empty and there is nothing to Restore to. Deployments can still be rolled back, because that’s a Cloudflare operation on what’s live. But restoring the code to an earlier state needs the repo. Connect GitHub and history starts accumulating from that point forward; it is not backfilled.

How to connect

1. In the console, choose Connect GitHub — offered right after Cloudflare in onboarding, or any time from Settings → Connections.
2. Authorize Typillar through GitHub’s own screen.
3. You’re returned to the console with GitHub connected.

As with Cloudflare, this is an OAuth grant issued by GitHub. Typillar never sees your GitHub password. It’s separate from signing in with GitHub — that proves who you are; this lets Typillar write your project’s code to your repositories.

What the connection is used for

• Committing generated code to your repository as ordinary commits.
• Maintaining history so every build maps to real changes you can review and trace.
• Enabling Restore — because history lives in your repo, returning to a prior version is reliable. See Deploys & rollback.
• Committing a deployable bundle on every production ship, so the repo runs without Typillar.

The deployable bundle

App source alone isn’t a running app: it calls /api/_data, /api/_pay and the rest, and something has to serve them. So every time you ship to production, Typillar commits the Worker code it actually deployed to .typillar/deploy/, with a wrangler.toml for each script:

package.json         npm install && npm run build
.typillar/build/     the compiler, and what this app has turned on
.typillar/deploy/
  README.md          how to deploy it yourself
  manifest.json      what was shipped, when, and by which model
  <app>/             the app Worker: your pages plus the /api/_* runtime
  <app>-admin/       your keys, and the calls that spend them
  <app>-live/        the realtime Worker
  <app>-assets/      signs asset uploads

Your credentials live on the -admin Worker, never on the app Worker — so the half that runs code an agent wrote holds nothing that authenticates you to Stripe, GitHub, or anyone else. See Your data and secrets.

Clone the repo, run wrangler deploy in each directory, and the app runs — on your own Cloudflare account, with no Typillar in the path. The D1 database, R2 buckets it binds to are the ones already in your account, so deploying from here reattaches to your live data rather than copying it.

Secret values are never written to the repo. Each wrangler.toml lists the secret names its script expects; you set them with wrangler secret put.

Changing the code by hand

The repo also carries the build. npm install && npm run build compiles the app source at the repo root with the same compiler Typillar uses — pinned to the same version — and rewrites the Worker files under .typillar/deploy/:

npm install
# edit App.svelte, add a page, change styles.css …
npm run build
(cd .typillar/deploy/<app> && npx wrangler deploy)

So a change you make by hand deploys exactly like a change an agent made. This is what makes the repo a project rather than a backup: you do not need Typillar to keep building on it.

Running it locally

npm run dev compiles the app, starts wrangler dev on it, and recompiles every time you save — so your pages and the whole /api/_* surface run on your machine, against Miniflare’s own D1, R2 and KV rather than your live ones:

npm install
npm run dev

Local storage starts empty and stays on your machine. The other Workers this app binds to are started alongside it, so service and Durable Object bindings resolve. A file that fails to compile prints the error and leaves the last good build running, so the dev server survives a typo.

Both commands also write the app’s own modules to .typillar/modules/ and a jsconfig.json pointing at them, so import { route } from 'router' — and every capability import — resolves in your editor. Both are generated and git-ignored; run either command once after cloning.

While you are still using Typillar, edit the app by talking to the agent — the files under .typillar/deploy/ are regenerated on every production ship, and a hand edit made there would be overwritten. Edit the source at the repo root.

One repository per project

Typillar creates a private repository named after the project’s slug, under the GitHub account that authorized the connection. There is no organization to pick: the grant is a user grant, and every project repository is created on that account. If a repository with that name already exists and isn’t one of Typillar’s, the connect is refused rather than committed over — rename the project (or the repository) and try again. Typillar marks the repositories it owns with a .typillar/repo.json file, which is how it tells them apart.

What the grant actually covers

Typillar connects as a GitHub OAuth app and asks for the repo scope. GitHub describes that scope as full control of your public and private repositories, and it offers no way to narrow it to one repository. So while Typillar only writes to the repositories it creates for your projects, the token it holds could reach any repository your account can.

If you want that boundary enforced rather than promised, authorize from a GitHub account that contains nothing else. Typillar will create the project repositories it needs on it.

How to revoke

• From Typillar — Settings → Connections → Disconnect next to GitHub. Typillar deletes its copy of the token and stops committing.
• From GitHub — remove the authorization under your GitHub account’s applications settings. Do this too if you want GitHub to invalidate the token itself.

Your repository and its full commit history remain after you disconnect — the code is yours and stays where it is.

Related

• Connect Cloudflare
• Project history