Can GitHub host your website? Pages vs a VPS

Can GitHub host your website? The short answer

Can GitHub host your website? Yes, when that website is a folder of static files, through a feature called GitHub Pages. No, when the site needs code running on a server. GitHub is a hosted home for Git repositories, plus the collaboration layer around them: issues, pull requests, code review, and permissions. It stores your code, and it does not run it.

That last sentence is the whole confusion, and it costs beginners weeks. The project is on GitHub, the code is right there, the tests pass, and yet the site is not online and the form saves nothing. Everything below is the detail behind that one line.

What GitHub actually stores

Git is a version control tool that runs on your own computer. It records every change to your files, so you can return to any earlier state and see who changed what. A repository, or repo, is one project plus its full history.

GitHub keeps a copy of that repository on its servers and adds the parts Git alone does not have: a web page for the code, issues for tracking work, pull requests for proposing changes, and permissions for deciding who may push. That is the product. For a wider tour, read what GitHub is and what people use it for, and if the two names still blur together, how Git differs from GitHub separates the tool from the service. GitHub is also not the only home available for a repository, since Gitea, Forgejo and other self-hosted Git servers do the same job on hardware you control.

What GitHub Pages will serve, and what it will not

GitHub Pages takes the files from one branch of your repository and publishes them at a public URL. GitHub's own documentation calls it a static site hosting service that takes HTML, CSS and JavaScript files straight from a repository. Static means the server returns each file exactly as it is stored. It reads the bytes and sends them. Nothing you wrote is executed on GitHub's side of the connection.

To turn it on, push the files, then open the repository on github.com, go to Settings, and open the Pages section. Pick the branch to publish from and the folder, either the repository root or /docs.

git init
git add index.html style.css
git commit -m "First version of the site"
git branch -M main
git remote add origin https://github.com/YOUR-NAME/YOUR-REPO.git
git push -u origin main

After the first build finishes, the site is at https://YOUR-NAME.github.io/YOUR-REPO/. One repository name behaves differently: a repository called YOUR-NAME.github.io publishes at https://YOUR-NAME.github.io/ with no path after it. If the URL returns a page reading "There isn't a GitHub Pages site here.", the build has not finished, or Pages is pointed at a branch or folder that holds no index.html.

Here is the rule made visible. Commit a file called save.php with any PHP inside it, then ask for it:

curl https://YOUR-NAME.github.io/YOUR-REPO/save.php

You get your own PHP source back, character for character. Pages returned the file because returning files is all it does. There is no PHP interpreter behind that URL, so the code has nowhere to run. A .py file behaves the same way, and so does every other language.

Why the form in your college project does not work

A feature that saves data has two halves. The browser half is HTML and JavaScript, and Pages serves that part without complaint. The server half receives the submission and writes it somewhere that outlives the request. Pages has no server half, so a form posting to /save.php reaches a file server whose only behaviour is to hand back files. Nothing is written anywhere, and the visitor sees a blank page or a failed request in the browser's network tab.

Two workarounds come up constantly, and both have a catch worth understanding. Keeping entries in localStorage stores them inside one browser on one device, so your teacher opening the same link sees an empty list, because their browser has its own separate storage. Putting a database address and password into your JavaScript does make the page work, and it also publishes that password: every file Pages serves can be downloaded by anyone, and the same file sits in a public repository. Deleting it in a later commit does not undo this, because the earlier commit still carries it in the history.

Hosted form services and backend platforms do fill this gap, and for a class project that is a fair choice. Be clear about what it means: the running code has moved to somebody else's server. GitHub is still only storing your source.

What GitHub Actions is for, if it is not hosting

Actions is CI, continuous integration. It runs commands for you on a temporary machine that GitHub starts when something happens in the repository, such as a push or a pull request.

name: build
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      - run: npm test

That machine is called a runner. GitHub creates it for this job and destroys it when the job ends, so a final step of npm start hosts nothing. The job holds the runner while your process stays in the foreground, then the workflow reaches its time limit and is killed, and no visitor could have reached that process from the internet in the meantime. When a step fails, the log ends with Process completed with exit code 1, and the machine is gone seconds later.

What Actions is genuinely good at is the work around your app. It builds the static files your site is made of, running a Vite or Jekyll build and publishing the output to Pages. It also runs your tests on every pull request, so a broken change is caught before it merges. And it can connect to a server you own and deploy there, which is the next section.

Where the line falls for the projects you are likely building

• A portfolio or resume site, hand-written or produced by a static site generator: yes. This is the case Pages was built for.
• A React or Vue app with no backend: yes. The build step produces static files. Set the base path to /YOUR-REPO/ first, or the built page asks for /assets/index.js at the domain root, that path does not exist, and the browser console fills with 404 errors.
• Project documentation, including a docs site whose search index is built at build time: yes.
• A contact form, or any page that stores a record: no. Something has to receive the submission and keep it.
• Login with usernames and passwords: no. Checking a password means running code the visitor cannot read, and every file Pages serves is readable by the visitor.
• A small API (application programming interface) for your mobile app to call: no. An API is a program that stays running and answers requests, and Pages has no running program.
• Anything that needs an API key, such as a payment service or an AI model: no, because the key would sit in a file the whole internet can download.
• A page showing data that refreshes on a schedule: yes, in a limited way. An Actions workflow can run each night, fetch the data, commit an updated JSON file, and Pages then serves that file. The page stays static and the data is as old as the last run.

What the alternative looks like: a server that runs your app

The moment a project needs to run code, it needs a computer that stays on and runs it. The usual answer is a VPS (virtual private server): a slice of a physical machine, rented by the month, with its own Linux installation, its own IP address, and root access for you. Your app runs there as a service that starts on boot, a web server such as Nginx sits in front of it on ports 80 and 443, and the database runs on the same box or on a second one. A VPS explained from the beginning covers the machine itself, and the range of things people actually run on one gives a sense of the scope.

Your repository does not move. GitHub stays the place the code lives and where review happens, and the server pulls from it. The simplest deployment is a git pull on the server followed by a restart of the service. The step up from that is an Actions workflow that connects over SSH (secure shell) once the tests pass and does the same thing for you, which is where CI meets a real host. What you take on is the part Pages was handling silently: system updates, the firewall, backups, and TLS (transport layer security) certificates. A worked deployment of Django behind Gunicorn and Nginx shows that shape from one end to the other, and the managed versus unmanaged question decides how much of the maintenance stays with you.

GitHub Pages limits, and where to check them

Free plan numbers move, so read GitHub's own page rather than trusting a figure in an article, including this one. As of September 2026, the GitHub Pages limits page lists a published site of no more than 1 GB and a soft bandwidth limit of 100 GB per month. It also documents a soft limit of ten builds per hour for the classic build path.

The same page carries a rule that matters more than any number. Pages is not intended to be used as free web hosting for an online business or an e-commerce site, and sites there should not handle sensitive transactions such as passwords or card numbers. Actions time is a separate allowance, with public and private repositories counted differently, and GitHub documents that on its Actions billing page. Check both pages before you plan around either.

FAQ

Can I host a Node.js or Python app on GitHub Pages?

No. Pages returns files exactly as they are stored, so a .js file written for Node, or a .py file, is sent to the browser as text instead of being executed. Request it with curl and your own source code comes back. Running server code needs a machine that stays on, such as a VPS or a platform that runs applications for you. GitHub Actions does not fill the gap either, because its runner is deleted the moment the job ends.

Why does my GitHub Pages site show "There isn't a GitHub Pages site here."?

That page appears when the URL exists but nothing is published under it. The usual causes are a build that has not finished, or Pages pointing at a branch or folder that contains no index.html. Open Settings, then Pages, and confirm which branch and folder are selected. Check the file is named index.html in lower case, because the URLs are case sensitive. If a workflow builds the site, confirm its latest run finished successfully.

Can a GitHub Pages site save data to a database?

Not on its own. The page can call an external service from JavaScript in the browser, and many students do exactly that, but the credentials for that service then sit in files anyone can download from your public repository. When the data matters, the code that talks to the database should run on a server you control, with the repository staying on GitHub.

Is GitHub Pages good enough for a portfolio site?

Yes. A portfolio is static content, which is the case Pages handles best. You get a public URL with HTTPS and a rebuild on every push. A custom domain works too: point your DNS records at GitHub and set the domain in the Pages settings. Move to a server only when you add something that must run, such as a contact form that stores the messages it receives.