What hosting does not do yet

Hosting is open to everyone.

This page is the short list of what hosting cannot do today, so you find out here rather than from a failed site.

There is no build step

Nothing from your repository is run on our side — not a build command, not a Dockerfile, not a git hook. A site is the files of one folder, served as they are.

So the folder you publish has to be the one your build already produced. Commit that output to the repository and name it in Folder in your repository; a folder that only exists on your computer, or only inside a workflow, is not on the branch we read. How you get it there — by hand, or from your own workflow on GitHub Actions — is yours to decide.

This is also why nothing on a site runs on our side: no server code, no database, no request handler. A site sends HTML, CSS, JavaScript, images and fonts to the browser, and the browser does the rest. What comes after static sites is not decided, and we would rather say so than guess.

Private repositories are not supported

We read your repository the way any visitor would, without signing in, so it has to be public. A private repository is refused when the site is created, before anything is charged, with:

your-name/your-repo (branch main) was not found on GitHub, or is not public — hosting takes public repositories only

To an anonymous reader a private repository and a repository that is not there look the same, which is why one sentence covers both.

Before you make a repository public so you can publish it, read the first part of Publish a site from GitHub: making it public publishes its whole history, not only the folder you had in mind.

One other way in is being built

The New site form shows three ways to start a site and offers two of them: Upload from your computer and From GitHub. Describe it, we'll build it is shown without a button, under the form’s own line:

Describing a site is being built. This page will say so when it opens.

It cannot take a site today, and there is no date for it. When it opens, the form will say so and these pages will follow.

A bare name needs a DNS provider that allows it

A site answers at https://<name>.oraicle.app, and that is the address it always keeps. On top of it you can put a name of your own — with something in front, like www.yourname.com, or the bare name, yourname.com. A name of your own comes with the Start, Business and Pro plans.

It takes two records in your domain’s DNS settings: one that proves the name is yours, and one that sends visitors to us. The console shows both, with the exact values to copy. Nothing answers on your name until we have found the first record in your own DNS and the certificate is ready — that is what stops anyone else attaching a name they do not own.

Keep both records in place. We look for the first one once a week, so a name you point somewhere else, or hand on to someone else, stops being served as yours. If the record is missing, we email you once. If it is still missing 7 days later, we take the domain off your site, and the site keeps answering at its own address. Put the record back before then and nothing changes. If we could not read your DNS that day, nothing changes either.

A bare name asks one thing more, and it is asked of your DNS provider, not of you. The record that sends visitors to us is a CNAME, and the DNS itself does not allow a plain CNAME on a bare name. Providers get past that with a record they call ALIAS, ANAME or a flattened CNAME. Most have one — Cloudflare, Route 53, DNSimple and Porkbun among them. If yours does not, put www.yourname.com on the site instead: the same two records, the same result.

Your email is not affected. Mail goes where a domain’s MX records send it, and neither record above touches those. The one case to look at first is an MX record that points at the bare name itself; move it to a name of its own, the way mail.yourname.com does, before you point the bare name at us.

A name whose DNS runs through the same company that runs our own servers cannot be attached from the console at all; if that is yours, write to hello@oraicle.me and we will attach it by hand.

What we do not promise

• We do not scan your files. Nothing here reads your pages looking for secrets or for malware. What the importer refuses, it refuses because it cannot serve it.
• We do not keep a copy of your site for you. Your repository is the original. Deleting a site removes our copy of the files; it does not touch anything on GitHub.
• We do not publish a figure for how often a site is reachable. What we can say is what the serving side does: sites are kept apart from each other, each serves only its own files, nothing a customer publishes runs on our side, and an automatic check confirms that every hour.