What happens when a deployment fails?

Use the Portal deployment status and build logs to understand the outcome, correct the project in GitHub, then publish again through the same connected workflow.

Documentation · Getting started

Deploy your first GitHub project.

Q: Can I reconnect GitHub later?

Do not assume a self-service reconnect control. Contact support if a repository connection needs to change so access and deployment configuration can be reviewed safely.

A practical guide to taking a supported static website from a GitHub repository to a Host Luma preview URL with HTTPS. It is written for your first deployment, but it also explains the checks, logs and repeatable workflow you will use for later changes.

Start the guide Check compatibility first

Estimated first deployment: around 10–20 minutes, excluding project fixesAudience: developers, founders, agencies and freelancersLast updated: 1 August 2026

What this guide covers

A connected publishing workflow, not a file-upload tutorial.

Host Luma publishes supported static website output from a connected GitHub project. Your repository remains the source of the project. The Host Luma Portal is where you create and manage the AI Hosting project, see deployment status and read build information. A successful deployment gives the project a permanent hostluma.app preview URL with HTTPS.

This guide is for a static website: a project that can be served as finished HTML, CSS, JavaScript, images and other assets after its production build. It can be plain HTML or a supported frontend project such as React, Vite, Astro or a Next.js static export. It is not a guide to running a long-lived Node server, PHP application, WordPress site, database, Docker container, server-side rendering workload or background worker. Those are different hosting requirements and are not part of the public AI Hosting workflow today.

Quick answer: if your production build creates a folder of static files that can be served without an always-on process, it is the right kind of project to prepare for this guide. If it works only while a development server is running, pause and assess the project before connecting it.

What you’ll need

Have these ready before you create the project.

A GitHub repository

The source of the website should be in a repository you can access. GitHub is the connected project provider available in the public workflow today.

A static production output

Plain HTML works directly. Framework projects need a normal production build that creates static files, commonly in dist, build or out.

A Host Luma account

You need an AI Hosting project in the Portal. The Portal remains the customer-facing place for project creation and deployment visibility.

Before spending time on connection: use the Supported Frameworks reference to check your project type. The framework name alone is not enough; the project must be configured to generate static output.

Before you begin

Confirm the project can build locally.

A local production build is the quickest way to distinguish a project setup issue from a hosting-side issue. It does not need to be an elaborate release process—just run the project’s usual production build and look at the output.

Make sure the repository contains the intended website, rather than an older experiment or a parent folder containing several unrelated projects.
For a framework project, run its normal build command on your computer and confirm it finishes successfully.
Know the build output folder and confirm that it contains an index.html file or the static pages you expect.
Check that browser-side environment values, external forms, APIs, analytics and booking links are valid for a deployed website.
Do not include credentials in the repository. A static website can use browser-side public configuration, but it should not contain server secrets.

You do not need Linux, cPanel, SSH or FTP for this customer workflow. You do need a project that can produce a finished static website from its repository.

Deployment map

Understand the path before you use it.

GitHub repositorySource project

Host LumaConnected project

BuildStatic output

PublishOutput deployed

HTTPS previewShare and review

Deployment historyStatus and logs

IterateUpdate in GitHub

Mermaid diagram source

flowchart TD
    A[GitHub Repository] --> B[HostLuma]
    B --> C[Build]
    C --> D[Publish]
    D --> E[HTTPS Preview]
    E --> F[Deployment History]
    F --> G[Iterate]

The diagram describes the public workflow. It does not imply a separate customer-facing runtime, rollback control, custom-domain route or additional Git provider.

Step by step

Deploy your first supported project.

Prepare your GitHub repository

Start with the repository that contains the website you actually want to publish. For a plain HTML site, the repository should contain the files that will be served. For a framework project, keep the source, package manifest and build configuration together so the normal build can reproduce the static output.

Commit the version you want to deploy. A clean, named commit is useful because it gives you a clear point of reference when you later compare a GitHub change with a deployment result. If the project is private, do not assume it will connect automatically: private repository access uses a per-application deploy-key flow that must be configured and verified for that application.

Check: the project builds locally, the right repository is selected, and the generated site is static. Do not point the workflow at a repository that starts an Express, Next.js SSR, Laravel or other application server.

Sign in to Host Luma

Sign in to the Host Luma Portal. The Portal is the source of truth for the customer project and its lifecycle. Use it to create the AI Hosting project, review its state and see deployment information; do not use cPanel or manual uploads as an alternative publishing route.

If you are a new customer, follow the normal account and AI Hosting purchase flow from pricing or the homepage. This guide begins once you can access the Portal and create or manage an AI Hosting project.

Create your AI Hosting project

Create the project through the Portal. Give it a clear project name so it is easy to recognise later in deployment history and in support conversations. The project is an orchestration record for the connected source and publishing workflow; it is not a general-purpose server you need to configure.

Keep the product boundary in mind here. AI Hosting is for supported static project output. A WordPress site belongs in Managed WordPress Hosting because it needs the WordPress, PHP and database model. A dynamic application needs a platform that explicitly provides the runtime and services it requires.

What to expect: the Portal records the project and gives you the place from which its connection and deployment information can be reviewed.

Connect GitHub

Use the project’s GitHub connection route in the Portal. GitHub is the provider available in the public workflow today. The connection creates the publishing relationship between the project and the repository; it is not permission to browse every repository in your account without review.

For a private repository, complete the per-application deploy-key configuration and verification required for that repository. For organisation-owned repositories, access needs assessment and authorisation for the connected GitHub setup. Treat organisation access as a support-reviewed requirement, not an unconditional self-service promise.

Keep the connection scoped to the right project. If a repository connection later needs to change, contact support rather than assuming a self-service reconnect control.

Choose the repository

Select the repository that contains the deployable website. If you have more than one similar repository, look for the project manifest, build command and source history you confirmed locally. The most common early mistake is connecting a starter repository, an archived copy or a repository whose root is not the website project.

Repository names can change over time, but renaming a repository is not documented as a friction-free customer self-service operation for an existing connected project. Plan a repository move or rename with support so the connection and access can be reviewed safely.

Check: the repository is the expected one, its latest intended commit is present, and any private access has been verified.

Deployment begins

Once the connected workflow starts, Host Luma checks the project and uses the applicable static publishing path. Plain static sites can be published as static files. For supported frontend projects, the build path uses npm to install dependencies and run the project’s build script, then publishes the generated static output.

The important distinction is between development source and production output. A Vite project commonly builds to dist; a Create React App-style project may build to build; a Next.js static export typically creates out. These are common patterns, not a substitute for your project configuration. The platform needs the output created by the production build, not a local development server.

Host Luma does not turn an unsupported dynamic application into a static project. If the build needs a long-running server, server-side routes, a database, a background worker or Docker, the right response is to reassess the hosting fit rather than repeatedly retrying the same deployment.

Review the preview deployment

On a successful deployment, the project receives a permanent hostluma.app preview URL with HTTPS. Use it to inspect the published result, share a work-in-progress site or complete a client review. HTTPS is included for the Host Luma preview URL.

The Portal records deployment status, history and build information. Use that record to see whether the project published, when the result was created and what the build reported. It is more reliable than guessing at server paths or re-uploading files.

Preview URLs are available today. Customer custom-domain attachment and CDN delivery are planned rather than available in the public workflow today. Do not promise a client that a custom domain is already attached simply because the preview deployment is working.

Verify everything works

Open the preview URL in a normal browser and check the user-facing result. Follow the primary navigation, test key pages, confirm images and fonts load, and review any external form, booking or analytics integration. Test a small screen as well as a desktop view; static output can publish successfully while a responsive layout or external browser-side dependency still needs attention.

For a client project, record the repository commit and the deployment result together in the approval or release note. That simple habit makes it easier to identify the source change behind a later issue without treating the Host Luma project as an unexplained black box.

Iterate through GitHub

The normal workflow for the next release is straightforward: change the project in GitHub, commit the change, push it, then publish through the connected workflow. Where automatic publishing is configured for the connected project, future changes follow that established route. Start with the deployment status and logs whenever a release needs attention.

A separate customer-facing manual redeploy button, deployment deletion control and self-service GitHub reconnect are not part of this public product promise. If you need to change access or connection configuration, contact support so the project can be reviewed safely.

What Host Luma checks

How build output is detected and why it matters.

The publishing path needs a static result. The project’s framework and configuration help determine the build route, but the final question remains whether the process creates publishable files.

Project pattern	Expected outcome	What to verify before connecting
Plain HTML	Files can be published directly.	The repository contains the intended `index.html`, assets and paths.
Vite, Astro, Vue or React static build	npm build creates static output, commonly `dist`.	The normal build completes locally and does not depend on a server runtime.
Next.js static export	A static export can create `out`.	Static export is configured; server-only and SSR features are not required.
Dynamic framework or server	Not a fit for the public static workflow.	Assess an appropriate runtime platform before connecting it.

Environment values: browser-side configuration is different from server secrets. Do not commit privileged credentials to a repository. If the site needs a private server-side secret to run, it is usually evidence that the project is outside the static publishing model.

Logs and recovery

Understand deployment logs before retrying.

Deployment status and build logs answer a focused question: what happened when the connected project was prepared for publishing? They help distinguish a build that succeeded from one that stopped because of dependencies, a script problem, missing static output or a project-fit issue.

Start with the status, then read the relevant build message. Compare it with the same production build on your computer. Correct the project in GitHub, commit the fix and publish again through the same route. Avoid creating a parallel manual upload path: it makes it harder to know which source actually produced the published site.

Build did not start as expected

Confirm that the connected repository is the intended project and that the package and build configuration live at the expected project root.

Build failed

Read the build message, reproduce the normal production build locally, then correct dependencies or configuration in GitHub.

Build passed but the site is wrong

Check the output folder, asset paths, client-side configuration and the preview URL before treating it as a hosting fault.

Read troubleshooting guidance Contact support

When a deployment fails

Use a short recovery loop.

A failed deployment is a result to investigate, not a reason to change several things at once. Keep the next attempt connected to a clear GitHub change so you can tell whether it fixed the actual cause.

Read the latest result

Start with the deployment status and the final useful log message. Look for the first project-level error rather than only the last line, which can be a consequence of an earlier failure.

Reproduce it locally

Run the same normal production build from the repository. If it fails locally, correct the project first. If it succeeds, compare the repository, build command, output and connection assumptions.

Make one focused change

Commit the correction to GitHub and publish through the same connected workflow. Keep the resulting status with the commit so that a future reviewer can follow the recovery path.

When to stop troubleshooting the build

Stop treating the issue as an ordinary static-build problem if the solution requires an always-on process, protected server environment value, database, server-side route, background worker or Docker service. That is useful information about the project boundary. A static front end may still be publishable if its required service already runs elsewhere, but Host Luma AI Hosting does not provide that custom service runtime in the public workflow.

Contact support when the hosting-side connection, preview URL, HTTPS, account access or deployment state needs investigation. Provide the project name, repository context, deployment time and the relevant log excerpt. Do not send credentials, deploy keys or private tokens in a support message.

Preview URLs explained

A stable place to review the published static site.

The permanent Host Luma preview URL is the public address for a successful AI Hosting project. It includes HTTPS, so you can open it in a browser, send it to a colleague or client, and use it as the deployment review location. It is not a temporary local development URL and does not require you to configure a server.

Use the preview URL after every meaningful deployment check: confirm the expected homepage appears, follow the most important internal links, check browser console issues in your own development process, and test any browser-side integration such as a third-party form or booking service. If your project uses relative paths, test a deep page as well as the homepage.

A working preview URL does not mean a custom domain is connected. Customer custom-domain attachment and CDN delivery are planned product work rather than capabilities to promise in the public workflow today. For current availability, use the Roadmap; for the product fit and limitations, read GitHub Website Hosting.

Common mistakes

Fix the cause, not the symptom.

Common issue	What it usually means	How to resolve it
Wrong build output	The project builds, but the publishing path cannot find the files visitors should receive.	Run the normal production build locally and verify the configured output is the actual static folder.
Missing static export	A framework project uses server-only features or has not been configured to export static files.	Use a static export if the project supports it, or assess a hosting platform for the required runtime.
Wrong repository	The connection points to a starter, archive or parent project rather than the website.	Confirm the selected repository, its latest commit and its build manifest before reconnecting or asking support.
Repository permissions	Private or organisation-owned access has not been configured for the project.	Complete the per-application deploy-key setup or contact support for access assessment.
Missing build command	The framework project has no working production build script.	Restore or correct the project build script, test it locally and commit the change.
Large assets	Images, videos or generated files make the project heavy or hide the files that matter.	Keep generated output and assets intentional; optimise media and remove unnecessary build artefacts from source where appropriate.
Repeated build failures	The project may be asking for an unsupported runtime rather than a simple correction.	Read the logs, identify the runtime requirement and reassess the project fit instead of repeatedly retrying.

Developer FAQ

Questions to settle before your next deployment.

Can I redeploy a project?

The normal re-publish route is to correct or update the project in GitHub and publish the next change through the connected workflow. A separate customer-facing manual redeploy control is not part of this public product promise.

Can I use a private GitHub repository?

Private repositories can be configured through a per-application deploy-key flow. That access must be set up and verified for the application; do not assume a private repository will publish without the required configuration.

Can I use a GitHub organisation repository?

Organisation-owned repository access needs assessment and authorisation for the connected GitHub setup. It is not presented as an unconditional self-service promise. Contact support before depending on that workflow.

Can I rename my repository?

Do not assume a repository rename automatically updates an existing project connection. Contact support before relying on a renamed or moved repository so access and deployment configuration can be reviewed safely.

Can I delete deployments?

We do not currently present a customer-facing deployment-deletion control as part of the public AI Hosting workflow. Contact support if you need help with an application or published project.

Can I reconnect GitHub later?

Do not assume a self-service reconnect control. If a repository connection needs to change, contact support so the application access and deployment configuration can be reviewed safely.

Do I get a custom domain?

Every AI Hosting project gets a permanent HTTPS preview URL. Customer custom-domain attachment and CDN delivery are planned rather than part of the current public workflow.

Next steps

Keep your publishing workflow understandable.

Once your first project is published, keep GitHub as the source of truth for website changes and use the Portal as the customer-facing record of project and deployment state. That gives you a repeatable path: change the source, review the result, then share the HTTPS preview URL.

For framework-specific compatibility, read Supported Frameworks. For the product boundary and project-fit explanation, read AI App Hosting and GitHub Website Hosting. For planned product work, consult the Roadmap. For the current purchase route, see Pricing.

Author: Host Luma editorial team. Technical review: Host Luma hosting team. Revision history: Version 1, 1 August 2026 — initial canonical getting-started guide.

Start free Sign in to the Portal