publish a site from your github repo

Import a repository, serve it at your own name and redeploy on every push. No build server, no DNS, HTTPS included.

reviewed

A subdomain here can do more than point somewhere else: it can serve the files itself. If your site is already a folder of HTML, CSS and images in a git repository, you can have it live under your own name in about two minutes, and keep it in step with the repo from then on.

what you get

Your repository is downloaded, checked and published under yourname.does.software, served over HTTPS from our servers. There is no DNS to configure and no certificate to renew, because the name is already ours and the wildcard certificate already covers it.

Every publish keeps the previous one, so you can roll back from the panel when a deploy goes wrong. You also get a file editor in the panel, for the one-line fix you would rather not open a laptop for.

what your repo has to contain

Nothing is built here. We serve what is in the repository, exactly as it is, so the repo has to hold the finished files: an index.html at the top of the branch you point at, plus whatever it loads.

If your project needs a build step, run it where you already run it and commit the output, or push a built branch. A repository that only contains sources will publish your sources, which is not what you want.

  1. Check there is an index.html at the top level of the branch you are going to import.
  2. Check the file types. Only html, css, js, mjs, json, txt, pdf, webmanifest, the images png, jpg, jpeg, webp, gif, svg, ico and the fonts woff, woff2, ttf are published; anything else is skipped.
  3. Check the size. No single file over 15 MB, and the whole site under 100 MB on the free and Starter plans, 300 MB on Pro.

import it

Connect the provider once from your account and the import list will show your repositories, private ones included.

  1. In account, connections, connect GitHub or GitLab. It is the same connection you can sign in with.
  2. Open your subdomain, go to the site section and choose to import from a repository.
  3. Pick the repository and the branch. Leave the branch empty to follow the default one.
  4. Publish. The first deploy takes a few seconds; when it finishes the name is already serving.

deploy on every push

Turn on deploy on push and we create a webhook in the repository. From then on, every push to the branch you chose publishes a new version by itself.

Only pushes to that exact branch count. A push to another branch, a deleted branch or a tag is ignored, so you can keep working without publishing half a feature.

If a deploy fails, the site that was already live stays live. The failure and its reason appear in the panel, and nothing is swapped until the new version has been downloaded and checked in full.

single-page apps and 404s

A framework router needs every URL to return the same index.html. Turn on the single-page app switch and any path that is not a real file is served index.html with a 200, which is what a client-side router expects.

With the switch off, a missing path looks for a 404.html in your own site and serves it with a real 404 status. If you do not ship one, the visitor gets our error page instead, which at least tells them the name exists.

the limits

Serving files and redirecting are exclusive. While the site is on, the root redirect and the path rules stay configured but stop serving. Email forwarding is untouched and keeps working alongside.

Versions kept for rollback go with the plan: one on the free plan, three on Starter, ten on Pro. The file count caps at 1000, or 5000 on Pro.

If your repository already holds the built site, this is a two-minute job and the push you were going to make anyway becomes the deploy. If it needs a build step, commit the output first.

keep reading

back to the questions