Skip to main content
How Can We Help?
< All Topics
Print

How to Deploy a Website from GitHub

Posted
Updated

If you keep your website’s code in GitHub, HubSeek can publish it for you. Connect your GitHub account once, choose a repository for your site, and you can deploy with one click or automatically every time you push a change.

What Is GitHub Deploy?

GitHub Deploy copies your code from GitHub to your website, so you don’t have to upload files by hand. A repository is the project folder that holds your code on GitHub, and a branch is one version of that code, usually called main. A push is what sends your latest changes up to GitHub.

Think of it like a print shop. Each deploy prints a fresh copy of your site in its own folder, and your website only switches to the new copy once it comes out right. If something goes wrong during a deploy, your live site stays as it was.

It works with PHP, Node.js, Laravel, static websites, and custom applications, such as one written in Rust or Go. Repositories can be public or private.

Before You Start

  • A GitHub account. You can create one for free at github.com.
  • A website that doesn’t use a 1-click install. GitHub Deploy isn’t available on sites using a 1-click app (WordPress, WordPress + WooCommerce, OpenCart, or Joomla), and the GitHub option won’t appear for them.
  • Worker processes, if your site needs them. A worker process is a program that keeps running on the server, as a Node.js app or a custom application does. Check that your plan includes worker processes before deploying this kind of app. Plain static sites don’t need one.
  • A recent backup, if you’re replacing an existing site. (See: Stay Safe: How to Back Up and Restore Your Website)

Replacing a site? Your site has no page to show until its first deploy succeeds, so test your setup on a staging site first if you can. (See: Website Cloning and Staging)

How to Connect Your GitHub Account

You only need to do this once. After that, you can use your repositories with any website in your HubSeek account.

  1. Log into your HubSeek control panel. Go to your client portal and open the control panel from there, or go directly to panel.hubseek.com.
  2. Click GitHub connection in the left sidebar.
  3. Click Connect. You’ll be sent to GitHub to sign in and approve the connection.
  4. Choose which repositories HubSeek can access. A repository you don’t select here won’t appear in the list when you set up your site.

How to Deploy Your Site

  1. Click Websites in the left sidebar, then click the website you want to deploy to.
  2. Click the GitHub tab, then click Configure GitHub deploy.
  3. Fill in the form using the table below, then save it.
  4. Click Deploy now. Saving the form doesn’t start a deploy, so this step runs your first one.
  5. Watch the Deployments list. Click View logs to see what’s happening or why a deploy failed.
Field What to enter
Repository The repository that holds your site
Branch or tag The version to deploy, usually main
Auto deploy on push Turn this on to deploy every time you push. It’s off by default, and while it’s off a push does nothing
Build script Commands to run after your code is copied. Leave it blank if your site doesn’t need building
Publish directory The folder in your repository that visitors should see. Don’t leave this blank on a static site

What to Put in the Build and Publish Fields

Kind of site Build script Publish directory
Plain HTML or PHP files Leave blank The folder holding your files, such as public
Built site, such as Astro Your build command or script The folder your build creates, often dist
Laravel Your build script public

Check Your Site Afterward

Visit your site and click around. Then go to https://yourdomain.com/.git/config, using your own domain. You should see a 403 or 404 error. If the page shows any text, your publish directory is exposing your repository’s Git files. Set it to a subfolder and deploy again.

How to Undo a Deploy

Each deploy stays on your account, so you have two ways to go back:

  • Pick a past deploy in the website’s GitHub tab.
  • Revert the change in Git and push. With auto deploy on, that publishes a new deploy without the change.

Why Didn’t My Deploy Work?

My repository isn’t in the list. HubSeek doesn’t have access to it yet. Update your repository access in GitHub, then try again.

I pushed a change and nothing happened. Check that Auto deploy on push is on and that you pushed to the branch you selected.

The deploy failed. Open View logs to see where it stopped. A build script has to finish without an error (exit code 0) for the deploy to go live. Until then, your site keeps showing the last good deploy.

My build can’t find Node.js. HubSeek installs Node.js in your site’s ~/.nvm folder when a site has a build script, but it may not be on your script’s path, and it may not be the version your project asks for. Have your script look in ~/.nvm and check the version.

My build stops with /dev/fd/63: No such file or directory. The build environment doesn’t support bash process substitution (< <(...)), even if it works on your computer. Use plain pipes or $(...) instead.

My site shows the wrong files or a 404 error. Check that the publish directory matches the folder that holds your site, and that at least one deploy has succeeded.

My static site shows an error even though the deploy worked. Check whether you’ve set up a worker process. A static site doesn’t need one, and one can send your visitors to a program that isn’t running.

Good to Know

  • A push can go live right away. With auto deploy on, anyone or any tool that can push to your branch can change your live site. GitHub’s branch protection lets you control who can.
  • Only one deploy runs at a time. Starting a new deploy cancels any that’s still running. You can also cancel one yourself, and your live site won’t change.
  • Files outside your repository need their own home. Each deploy is a fresh copy of your repository, so files that aren’t in it won’t be in the next deploy. For images and other large files, you can create a subdomain such as assets.yourdomain.com and link to them there.
  • Keep passwords out of your repository. Public settings can go in a committed .env.production file. Real secrets belong in a file outside the deploy folders, such as ~/shared/.env.
  • Old deploys take up disk space. They aren’t removed automatically, and Node.js adds about 320 MB per site. Don’t delete deploy folders by hand. Keep each deploy small instead, for example by removing node_modules at the end of your build, and contact support if you’re running low.
  • Test redirects and error pages on the live site. Web servers handle .htaccess files differently, so a custom 404 page that works elsewhere may not work here.
  • Clones and moves lose the connection. Pushing a staging site live, cloning a site, or moving it to another account keeps its deploy history but not its GitHub connection, so you’ll need to reconnect it. Backups work the same way.
  • You can disconnect at any time. Your site keeps running and no files are removed. If you disconnect GitHub from your whole account, every website using it is disconnected too.

What’s Next?

Need help? Log into your client portal, click Support in the top menu, and open a new ticket.

Table of Contents