Documentation · Getting started

Connect GitHub to a Host Luma project.

Connect the repository that contains your supported static website, then use the Host Luma Portal to follow the publishing result. This guide explains the current GitHub workflow, private repository access and the checks that prevent the most common connection problems.

Audience: developers, founders, freelancers and agenciesEstimated setup: 10–20 minutes, excluding project fixesLast updated: 1 August 2026

Before you connect

Confirm that the repository is a fit for the current publishing model.

Connecting GitHub does not change the kind of application Host Luma can publish. The public AI Hosting workflow is designed for a repository that produces finished static files: HTML, CSS, JavaScript, images and other assets that can be served without an always-on application process. The repository remains your source of truth; the Portal is where you create and manage the project, review its status and read deployment information.

A plain HTML website can be a fit. So can a supported frontend project that completes a normal production build and creates static output, such as a Vite, Astro, React, Vue or Next.js static-export project. Read Supported Frameworks before connection if you are not sure. A framework name alone is not evidence that a project can be published as a static site.

01

A GitHub repository

You need access to the repository that contains the website source you mean to publish, not a starter, archive or unrelated parent project.

02

A tested static output

For a framework project, run the normal production build locally and identify the folder containing the finished site.

03

A Host Luma project

You need an AI Hosting project in the Portal. Create and manage it there; do not substitute cPanel, SSH, FTP or manual uploads.

Before you begin: make the repository understandable.

A connection is easier to review when the source has one clear purpose. If you are working from an AI-assisted starter, take a moment to remove unused experiments, confirm which folder is the website and commit the version that you expect to publish. You do not need to make a release process complicated; you need enough clarity to tell the intended site apart from an old prototype.

For a framework project, local verification is the most useful pre-connection check. Run the same normal production build that the project uses for release. Then open the generated output folder and confirm that it contains the website you expect. This catches a missing static export, broken dependency, wrong output path or server-only assumption before it becomes a connection ticket. For a plain HTML site, open the entry page locally and confirm the repository includes its assets and relative paths.

Check before connectionWhy it mattersGood result
Repository identitySimilar project names, starter copies and archive branches are easy to confuse.You can identify the exact repository and commit that contains the intended website.
Production buildA development server working on your computer does not prove static output exists.The normal production build completes without requiring an always-on server.
Static outputHost Luma publishes finished files, not development source or a running process.The generated folder contains an entry page and the assets the site needs.
Public configurationAnything delivered to a browser can be inspected by a visitor.The site contains no private credentials, deploy material or server-only secret.

How it works

GitHub supplies the source; Host Luma publishes the static result.

The connection creates a defined publishing relationship between one Host Luma project and one repository. It is not a general instruction for Host Luma to browse unrelated repositories in your GitHub account. Once the connected workflow processes a supported project, the platform can build and publish its static output, then record the result in the Portal with a HTTPS preview URL, deployment status and logs.

GitHub repositorySource code and project configuration.
Host Luma projectCustomer-facing project and connection record.
Static buildApplicable supported build path creates finished files.
PublishStatic output is made available for review.
HTTPS previewStatus and logs remain visible in the Portal.

Linear alternative: select the right GitHub repository, connect it to the correct Host Luma project, allow the supported static workflow to process it, then use the Portal’s status and preview result to review the outcome.

flowchart LR
  A[GitHub repository] --> B[Host Luma project]
  B --> C[Build static output]
  C --> D[Publish]
  D --> E[HTTPS preview and deployment record]

Connection guide

Connect the repository in a deliberate order.

These steps avoid relying on unverified controls or guessing at server configuration. Labels in the Portal can change as the product evolves, so use the GitHub connection area within the project you intend to publish rather than looking for a separate server or cPanel workflow.

01

Prepare the intended repository.

Open the repository in GitHub and confirm that it is the website project you mean to deploy. For plain HTML, the repository should contain the site files and entry page. For a framework project, the source, package manifest and build configuration should describe one reproducible production build.

  • Commit the version you want to connect so that you have a clear reference point later.
  • Run the normal production build locally and confirm it completes.
  • Check the generated output contains the expected index.html file and assets.
  • Keep credentials, private keys and server secrets out of the repository.
02

Open the correct AI Hosting project in the Portal.

Sign in to the Host Luma Portal and open the AI Hosting project that should own this connection. The project is the customer-facing record for the connected source and publishing lifecycle. It is not a general-purpose server to configure.

If you do not yet have an AI Hosting project, follow Deploy Your First GitHub Project for the complete first-deployment path. Keep Managed WordPress and AI Hosting separate: a WordPress website belongs in the Managed WordPress workflow, not this GitHub static-publishing route.

03

Choose Connect GitHub in the project.

Open Repository & advanced settings for the project, then choose Connect GitHub. GitHub opens its authorisation flow and returns you to the Portal when that step is complete. The connection is limited to the projects you choose through the GitHub App; it is not permission to browse unrelated repositories.

Do not paste a personal access token into a repository, log, support email or browser-side configuration to work around an access problem. If GitHub does not return you to the Portal, restart the connection from the project and use the diagnostic steps below.

04

Choose the GitHub projects, repository and branch.

If GitHub asks you to choose projects, select the repositories that the Host Luma GitHub App may access, then return to the Portal. In the project, choose the repository and branch that contain the deployable website. Check its name, current commit, build configuration and project root before proceeding. Many early problems start here: a starter repository, an archived copy or a parent repository was selected instead of the actual website.

Then choose Use this project and publish. Host Luma creates the project’s deployment access, installs a repository webhook, verifies that access and queues the first deployment. This also enables Auto Publish for the connected project. You do not need to generate, copy or send a deploy key yourself.

05

Review the first deployment and manage the connection.

Review the Portal’s project state, deployment status and build information. A successful deployment gives the project a permanent hostluma.app preview URL with HTTPS. Open that URL and check the homepage, key links, assets and browser-side integrations.

From the same Repository and advanced settings area, connected projects can use Reconnect GitHub, Change Repository, Change Branch, Refresh Webhook and Return to HostLuma project. Use Deploy Latest when you want to queue the latest connected source manually. If the result fails, start with the first relevant connection, repository or build message. Reading Deployment Logs explains how to separate repository access, dependency, build, output and publish-stage problems.

Repository access

Use the smallest practical repository scope.

Repository access is part of the publishing configuration. It should be limited to the source the connected project needs, reviewed when it changes and treated as a security boundary. The connection should never become an informal workaround for access to unrelated customer, agency or personal projects.

Repository situationCurrent guidanceWhat to do
Public repositoryGitHub is the live connected-project provider. The project must still be a supported static website.Confirm the correct repository, current source and production output before connection.
Private repositorySupported through the Portal’s GitHub connection flow.Authorise GitHub, select the repository and branch, then let Host Luma create and verify project-specific deployment access before publishing.
Organisation-owned repositorySupported when the GitHub App installation has access to that organisation repository.Choose the GitHub projects the App may access. If organisation policy requires administrator approval, complete it in GitHub, then return to Host Luma to select the repository.
Renamed or moved repositoryConnected projects provide Change Repository and Reconnect GitHub.Use the connection flow again, choose the intended repository and branch, then review the queued deployment before treating the new source as live.
Another Git providerNot in the public connected-project workflow today.GitHub is the current route. Check the Roadmap for product direction; do not attempt an unsupported workaround.

Private repository access is a project-level check.

Private access is intentionally more deliberate than connecting a public repository. The Portal connection flow creates project-specific deployment access, adds the webhook used for publishing updates and verifies that the selected branch can be read before saving the new source. Treat a failed verification as an access problem to investigate, not a reason to publish the same source manually from another route.

Before asking for help, confirm that the repository still exists, that the project is connected to the intended source and that a recent intended commit is present. If the repository is owned by a GitHub organisation, make sure the person completing the connection can approve the Host Luma GitHub App’s access to the chosen projects. Some organisations require an administrator to approve that request in GitHub.

Choose the repository, not just a familiar name.

A connected repository should contain the project that will actually build. A common failure pattern is a parent repository containing several experiments, a repository that only contains design files, or an older copy of the site that still happens to build. Review the package manifest and build configuration for framework projects, or the entry page and asset layout for static HTML. If a project later moves or is renamed, use Change Repository or Reconnect GitHub, make the new selection and review the next deployment before you rely on it.

Permissions explained

Connection access is for publishing one project, not administering your GitHub account.

Host Luma needs enough repository access to process the source selected for a connected project. The GitHub flow lets you choose the projects available to the Host Luma GitHub App, then the Portal shows the accessible repositories and their branches. Host Luma stores the selected repository and branch as the project source; the customer’s OAuth token is used only for the connection exchange, rather than saved as the project credential.

As the project owner, you remain responsible for deciding which repository is connected, who can change that repository, and whether its content is suitable for a public preview. Connecting a repository enables Auto Publish for the project. You can change the Auto Publish setting in the project when you want a manual release rhythm; use Deploy Latest to queue the latest connected source manually. Keep credentials and sensitive data out of static source because anything included in browser-delivered files can be inspected by visitors.

REPOSITORY

Choose one clear source.

Use the project repository that has the code, configuration and release history you intend to publish.

PEOPLE

Review who can change it.

Anyone with the ability to change a connected source may affect the next publishing result where automatic publishing is configured.

SECRETS

Keep them outside static output.

A browser-delivered site is not a safe place for server credentials, private API keys or deploy material.

For agencies, this boundary is especially useful during handover. Decide whether the client, the agency or a named shared team owns the repository before connection. Record the project name and repository context in your handover notes. If ownership or access needs to change, use Support to review the connection safely instead of sharing credentials or relying on an old employee account.

Troubleshooting

Fix the connection assumption before changing the build.

Connection failures and build failures can look similar if you only see a final failed status. Work from the earliest relevant message and make one focused change at a time. Do not create a parallel FTP, cPanel or manual-upload path to work around a connected-project problem; it makes it harder to know which source produced the published website.

SymptomLikely causeRecommended action
The wrong site is being processedThe selected repository is a starter, archive or parent project.Compare the repository, latest intended commit, package/build files and local output. Correct the connection through the supported project route or ask Support to review it.
Private repository cannot be readThe selected GitHub App installation cannot access the repository, or project-specific deployment access did not verify.Restart the project connection, choose the repository in GitHub and review the result. Do not share private keys or tokens; send Support the project name, repository context and time of the result if it continues.
Organisation repository access is unclearThe GitHub App installation was not granted access to the organisation repository, or an administrator approval is pending.In GitHub, choose the projects the App may access and complete any organisation approval. Then return to the Portal and select the repository and branch.
Repository checks pass but deployment failsThe problem is likely dependencies, the production build or missing static output.Read the deployment log, reproduce the normal production build locally and check the output folder. See Reading Deployment Logs.
You need to reconnect, move or rename a repositoryThe connected project still points at the old source.Use Reconnect GitHub or Change Repository in Repository and advanced settings, then choose the intended repository and branch and review the new deployment.

When to contact Support

Contact Support when account access, the Portal connection flow, private repository verification, preview HTTPS or a hosting-side status needs investigation. Include the project name, repository context, approximate deployment time, what you expected and the relevant non-sensitive log message. Do not send passwords, access tokens, deploy keys or private keys.

Developer FAQ

Questions to settle before the next push.

Can I use a private GitHub repository?

Yes. Complete the Portal’s GitHub connection flow, select the repository and branch, then let Host Luma configure and verify the project-specific deployment access. You do not need to create or send a deploy key yourself.

Can I use a GitHub organisation repository?

Yes, if the GitHub App installation can access that organisation repository. Choose the projects the App may access in GitHub. If your organisation requires administrator approval, complete it there before returning to the Portal.

Can I use GitLab, Bitbucket, Forgejo or Gitea instead?

GitHub is the live connected-project provider in the public workflow. Other Git providers are planned product work, so this guide does not provide a workaround or connection procedure for them.

Can I reconnect GitHub, move a repository or rename it myself?

Yes. Open Repository and advanced settings in the connected project, choose Reconnect GitHub or Change Repository, complete the GitHub flow, select the intended repository and branch, then review the resulting deployment.

Do I need cPanel, SSH or FTP?

No. The AI Hosting customer workflow is the Portal plus the connected GitHub project. cPanel, SSH and FTP are not alternative publishing routes for this product.

What happens after I push a change?

Connecting a repository enables Auto Publish for the project. When Auto Publish is on, GitHub updates follow the connected publishing route. You can change the Auto Publish setting in the project, or use Deploy Latest to queue the current source manually. Review the next deployment status, log and HTTPS preview result.

Can I connect a server-rendered application?

No. Connecting a repository does not make a long-running or server-rendered runtime available. Host Luma AI Hosting currently publishes supported static build output. See Supported Frameworks for the current boundary.

Can I change the connected branch?

Yes. Connected projects provide a Change Branch control in Repository and advanced settings. Select an existing branch, then review the deployment it queues before relying on the new source.

Screenshots and next steps

Use real product evidence when a visual would remove ambiguity.

No approved, genuine Host Luma screenshot currently documents the AI Hosting GitHub connection state. Do not use a generic Portal, billing or hosting image as though it were evidence of this workflow. This guide remains usable without a screenshot because the required actions and recovery paths are written in text.

Related documentation

For the full product boundary, read AI App Hosting. For current plans, see the Roadmap. For the current purchase route, see Pricing. If the project connection requires review, contact Support.

Author: Host Luma editorial team. Technical review: Host Luma hosting team — publication sign-off required. Revision history: Version 1, 1 August 2026 — initial GitHub connection guide. To report an inaccuracy, contact support@hostluma.co.uk.