Questions & answers

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Yes. In .mdx collections, editors can insert the components you declare in orbit.config.yaml — Orbit builds the tag from a small form. Preview shows a placeholder card; your Astro site renders the real component at build. Editors can create new MDX pages wherever your collection’s glob accepts .mdx and the MDX integration is installed — that’s your call as the developer. See the MDX components docs.

Yes. Alongside page content, Orbit can edit standalone JSON data files — a nav menu, footer links, a small site config. List each file under data: in orbit.config.yaml and editors get a form for it (inferred from the JSON shape) under a Data heading. Only the files you list are editable, so editors stay clear of the rest of your code. Prefer a .ts data file? Have it import the JSON and Orbit edits the JSON. See Editable data files.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Yes. Nest your collections however you like — by year, section or category. Orbit shows each collection as a folder tree and follows your content config’s glob exactly: new pages go in the folder you pick, with the right file type, and only where your site will read them. Editors add pages to existing folders; a developer can also let them start new ones, per collection, with newFolders: true. It’s off by default because a new folder changes the page’s URL and can break a site whose routes aren’t ready for it — see Letting editors create folders for the checks and example route code. See What Orbit edits.

If a folder has no new page icon when you hover it, your developer has closed it to new pages — usually because it’s an archive, or a set of pages the site’s code expects to stay fixed. The pages already in it can still be edited and published; only adding is switched off.

It’s set per section in the site’s settings (noAddTo, or addTo to allow only certain folders). If you need a page there, ask your developer. Details: Folders that don’t take new pages.

Yes — hover the folder in the sidebar and click its bin icon. Orbit asks first, and lists the pages inside, because deleting a folder deletes everything in it: its pages, any folders inside it, and other files such as images.

Nothing changes on your live site until you publish, and until then pages that were already on the site can be brought back from Changes. More: Deleting a folder.

Yes — open the page and click Move to folder… on the Page tab, then choose the folder (for example, to put an old post in the archive). The page keeps its history, and Orbit fixes its image and link paths so they still work. Remember that the folder is part of the page’s web address, so its URL changes. More: Moving a page.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Astro 2 through 7, including the newer content-layer loaders. Orbit reads your content config the way Astro does and adapts to it — you don’t change your site to fit the tool.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit can still open it manually and edit frontmatter generically, but it won’t be auto-detected and you lose typed fields, dropdowns and required markers. Adding a content config gives a much better editing experience — see repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.

No. Orbit hides git behind plain-language actions — Publish, Get latest, Undo — and never shows a merge conflict or a command line. Under the hood it’s ordinary git, so your developers keep all their normal tools and history.

Just git, which Orbit uses to talk to the site. Many Macs have it; on a new one, Orbit’s start screen offers to install Apple’s free developer tools (which include git) in one click. To open a private site on GitHub, click Sign in with GitHub in Orbit (1.1 and later) — how; on other hosts, sign the computer in once — how. Otherwise Orbit is a single app: no dev server and no command line for editors. Bundling git inside Orbit is on the way.

Orbit MD can only reach the repositories you add it to on GitHub, and only to read and change their files — it can’t change your account, delete repositories, or see anything else. GitHub’s approval page says it will “act on your behalf”: that means your edits are saved as you, with your own access, so GitHub still decides what you can publish.

Your sign-in stays on your computer, in its Keychain. Nothing goes to us — Orbit talks to GitHub directly. Sign out any time from the name at the top right, and revoke access on GitHub under Settings ▸ Applications. More about signing in.

Because it means one less thing to sign up for, trust or pay for.

• No new account. Orbit uses the access to your site’s repository you already have — there’s no extra login, password or user list to manage.
• Your content doesn’t pass through anyone else. Changes go from your computer straight to your own repository. Nothing is stored on Orbit’s servers, which matters for agencies and for clients with data rules.
• No server to trust or rely on. There’s no per-seat hosting cost, and nothing stops working if a service has a bad day.
• It works offline. Edits are saved on your computer; publishing happens when you’re connected.
• It follows your real site. Orbit reads your site’s own content settings and checks pages against them — the same rules your site’s build uses.

The trade-off is that each person installs it once, like any desktop app.

A site is one connected repository you edit in Orbit. Your first one is free; adding a second is where Pro or a Team seat comes in. You’re never locked out of sites you already manage, and because a licence doesn’t expire, there’s no way to lose access to your work.

Orbit’s Help menu links straight to this site. Orbit MD Guide opens the docs, FAQ opens these questions, and Email Support… starts an email to support@orbitmarkdown.com. Questions about buying go to sales@orbitmarkdown.com. Because the guide and FAQ live online, you always get the latest version.

Publishing is gated by git push access — someone who can’t push to the repo can’t publish through Orbit, because it’s ordinary git underneath. Orbit doesn’t add its own permission layer. The Editor and Developer modes only change the interface (a simple surface vs the full controls), not who’s allowed to push — that stays with your repository and host.

Orbit never stores your credentials: paste a plain repo URL (no token or password in it — those are rejected) and authentication goes through your system’s git credential helper or SSH agent, exactly as git on the command line would.

Yes, for the content you write. Orbit flags images that have no description (alt text) and headings that skip a level, in a red note above the page — click a tip to jump to it. It’s advice only; it never stops you saving. Your site’s design and layout are your developer’s side, so Orbit doesn’t check those.

Saving puts your change on the preview site — Orbit sends it there in the background a few seconds after you save. Publishing puts it on your live site: approvers click Publish on the page; editors click Ask to publish, and an approver publishes it (or sends it back with a reason). Every page shows where it stands — New, Live, Changed or Waiting for approval — and Unpublished lists everything that isn’t live. Nobody needs to visit GitHub. If your site uses a single branch, there’s no preview step: Publish takes changes straight live.

See Branches & publishing and Setting up your GitHub repository.

Someone changed that page or file directly on the live site — usually a developer fixing something quickly. The copy on your preview site is now older than what’s live, so Unpublished lists it apart, and Orbit won’t publish over it (that would put the older version back).

To clear it, a developer clicks Bring in live’s changes: the live version is copied to the preview site, and nothing on the live site changes. Then edit and publish as usual. See Working alongside developers.

Anyone can ask to publish; only approvers can publish. Who’s an approver is decided on GitHub, not in Orbit: the live branch is protected, and only the people on its bypass list can change it. So small content changes can go live without the repository’s owner being involved, while the live site stays protected. With Sign in with GitHub (Orbit 1.1 and later), Orbit reads this from GitHub, so editors see Ask to publish and approvers see Publish without anyone setting it.

Setting that up is a one-off job for whoever manages the repository: Setting up your GitHub repository.

Use the Preview ↗ and Live ↗ buttons — on the Dashboard they open the site, and on a page’s Page tab they open that page. They appear once your developer has filled in the site’s addresses in Site settings ▸ General. To open the page itself (not the home page), they also set each section’s Address in Site settings ▸ Collections — for example /blog/{slug}. Live ↗ is greyed out for a page that hasn’t been published yet.

There’s one Orbit app for every site generator. It works with Astro (no setup), and with Gatsby, Next.js and Nuxt (with a short content map); Hugo, Eleventy and Jekyll should work with a content map but haven’t been tested yet. The download page shows each one’s status.

There’s a macOS app today; Windows and Linux are on the way — get in touch from the download page if you’d like to hear when. One licence covers every site generator, so you don’t pay again for a different one.

Orbit MD is free for a single site — fully featured, nothing held back. To manage more than one site, there are two one-time options:

• Pro — £29 once. One person, unlimited sites, on up to 2 computers.
• Team — from £129 once. One key for the team, one computer per seat: 5 seats for £129, 10 for £249, 25 for £549.

There’s no subscription. A licence never expires, and you’re never locked out of a site you already manage. Every 1.x update is free; if there’s ever a version 2, owners get a discounted upgrade and 1.x keeps working. One licence covers every site generator Orbit supports, and Pro and Team include Orbit Extras — ready-made sites set up for Orbit. See the pricing page.

A Pro licence is for one person, on up to 2 computers. A Team licence is one key shared by the team, working on one computer per seat. So:

• A client editing their own site — Free is all they need, however many sites their agency or freelancer works on.
• A freelancer with several client sites — Pro, once. It works on any site, whoever owns it.
• An agency or in-house team — a Team licence with a seat for each person who edits. When people change, the one leaving removes the licence on their computer and the seat is free for the next person.
• If more than five people in your organisation edit with Orbit, we ask you to buy a Team pack for them, even if each of them only edits one site.

A freelancer who joins an agency for a while can keep using their own Pro licence — the agency doesn’t need a seat for them. And if you build sites for clients, you can buy or give them licences as part of the job — see Licences for your clients.

Your key is emailed to you straight after you buy. In Orbit, open Help ▸ Licence Key…, paste it and choose Check key. Orbit activates it on that computer once (you need to be online for that moment), then never checks again — so it works offline and can’t lock you out. Pro works on 2 computers, Team on one per seat. See Licence keys.

Orbit edits content that lives in files in your repository: content collections, Markdown pages in src/pages, and JSON or YAML data files. Words written inside .astro pages or components, data written as code, and content from a CMS or API aren’t files Orbit can edit.

Open the site in Orbit and go to Site settings ▸ What Orbit edits: it lists everything editors can edit, and everything Orbit found but can’t, each with the reason and a link to the fix. Where to put content covers each case.

Yes. Add the repository as usual: if it holds several sites in sub-folders (a monorepo, such as sites/blog and sites/docs), Orbit lists them and asks which one to edit. Each site uses its own orbit.config.yaml and keeps its changes inside its own folder, and each appears separately in Your sites. See Repo layout.

Orbit reads its rules for your site from orbit.config.yaml in the repository. If that file can’t be read at all — most often because a git merge left conflict markers (<<<<<<<, =======, >>>>>>>) in it — Orbit doesn’t know which sections are meant to be locked, so it locks every section rather than quietly dropping your rules. Editors see a banner saying so.

A developer opens Site settings to see the problem and its line number, fixes the file by hand (keep one version, delete the markers), and pushes it. Smaller mistakes — a misspelt setting, a value Orbit doesn’t accept — don’t lock anything: they’re ignored and listed at the top of Settings. See orbit.config.yaml.