Mirror your Odyn projects to GitHub
One-way sync from Odyn to a GitHub repo you own. Source files, versioned builds, auto-generated README, and free jsDelivr CDN URLs for public repos.
Connect your GitHub account once, link a repo per project, and every production deploy lands in that repo: source files, the versioned build, a regenerated README, and a v{n} Git tag. Staging deploys are not synced — only production.
You own the repo. Clone it, fork it, hand it to a client, or serve it from another CDN. Odyn keeps the editor and the build; your GitHub is the durable copy.
Connect your GitHub
Open Settings → Integrations and click Connect. You'll be sent to GitHub to install the Odyn GitHub App. Pick whether to grant access to all your repos or only a selected list — Odyn can only push to repos you explicitly grant.
No long-lived OAuth tokens are stored. Install tokens are signed on demand and expire in an hour.
Link a project
In a project's Settings → Backup tab, either pick an existing repo or create a new one. Most projects get a fresh repo per project.
If the App is already installed on your account but no Odyn org has claimed it yet (common if you installed from github.com directly), a one-click "Link to this org" path picks it up.
What lands in the repo on a production deploy
src/— your current source filesdist/v{n}/— built artifacts for that specific deploy, immutable, never overwrittendist/latest/— the most recent deploy's built artifacts, overwritten on each pushREADME.md— auto-generated, with the current version, deploy timestamp, and ready-to-paste jsDelivr URLs for every artifact- Git tag
v{n}for the deploy
The commit is layered on top of whatever else is in the repo — a custom README you added by hand, CI workflows, anything — so unrelated files survive untouched.
Public or private — pick based on what you want next
Private repos work as a pure backup. Your code is mirrored, nobody else can see it, and you keep serving production traffic from Odyn's CDN.
Public repos unlock jsDelivr: a free global CDN that serves any file in a public GitHub repo. Pin your <script> tag to a v{n} Git tag and you get an immutable, cached-forever URL.
Two equally valid serving strategies. Pick based on whether you're comfortable with your code being readable.
Using jsDelivr
If your repo is public, every artifact in dist/v{n}/ is reachable as:
https://cdn.jsdelivr.net/gh/<owner>/<repo>@v{n}/dist/v{n}/bundle.jsThe auto-generated README lists the exact URLs for the current deploy so you can paste-and-go. Tagged URLs (@v{n}) are immutable and cached for a year. Branch-path URLs (@main/dist/latest/...) lag by up to 12 hours and aren't recommended for production embeds.
Three reasons to flip it on
- Backup. If Odyn ever goes away, your code is already on GitHub. Not in our database, not behind our login — yours.
- Client handoff. Hand a repo URL to a client at the end of an engagement. Everything they need to keep the site running is in it, with version history.
- Alternate hosting. Build in Odyn, serve from jsDelivr or your own CDN. The repo is the bridge.
This is the first piece of a broader workstream on code portability and durability. More coming.