Deploy your first application

Start a new deployment

1. 1Open Hosting > Applications and choose Deploy Application.
2. 2Enter a name that you and your colleagues will recognise.
3. 3Complete Application, Configure, Resources and Review in that order. Next moves to the next page. Return to an earlier tab to change an answer; values stay while this drawer remains open.
4. 4If you need to stop, save a draft before closing. A draft stores the form; it does not publish the application.

Choose your source

You have a GitHub URL

1. 1Paste the repository's root URL into Git repository. Use the repository page, not a link to one file or a pull request.
2. 2Leave the field. The loading indicator means GD is checking the repository and preparing suggested settings.
3. 3A public repository can be inspected without connecting its owner. A private repository must be accessible through a GitHub connection in this workspace.
4. 4If access fails, open Browse Projects and check the connected accounts. Grant the GitHub installation access to the repository when necessary, then try again. Connecting GitHub in a different workspace does not grant this workspace access.
5. 5Review the selected repository and branch. A branch is a named line of development, commonly main; select the one you intend to publish.

You want to choose from connected GitHub projects

1. 1Choose Browse Projects beside Git repository.
2. 2Select the GitHub account, then search for the permitted repository.
3. 3If the repository is absent, check that the correct account is selected and its GitHub installation allows that repository. Update permissions through the available GitHub configuration action.
4. 4Select the project and allow detection to finish. Confirm the branch before continuing.

Review the detected configuration

Detection reads project files and suggests a stack, framework, runtime version and commands. A stack is the technology your application uses; the runtime is the software that executes it. Suggestions still need checking against the repository's instructions.

1. 1On Configure, confirm the stack and framework. Do not choose a familiar framework merely because its name looks similar to the one in the project.
2. 2Confirm the runtime version supported by the project. A newer version can require code changes.
3. 3If the repository contains several applications, set Project directory to the folder containing this application. Build files and commands must work from that folder.
4. 4Review Advanced build settings. Install downloads dependencies; build prepares the application; start launches the server. For a static site, review the published output directory instead of assuming a server command is needed.
5. 5Confirm the listening port for a server application. The app must listen on the configured port and a container-reachable address, not only its own loopback address.
6. 6Review any worker or concurrency settings offered for this runtime. More workers do not increase the workspace's CPU or memory allocation. Start with detected values; increase only after measuring resource usage.

Choose stages and resources

Production is the version intended for real visitors. Development, Testing and Staging can be enabled when you need separate places to prepare or verify changes. Enabling stages consumes resources even though they belong to one application.

• Choose branch-based deployment when each stage should follow a selected branch. Check every branch-to-stage assignment before deploying.
• Choose manual promotion when you want a deliberate decision before moving a release between stages. Check the source and destination each time you promote.
• Keep only Production when you do not need the other stages yet. Do not enable additional stages simply because the controls are present.

For the database, choose Create New if this is a new application's data store; Use Existing if the application must use a database already in this workspace; or no database when the application does not need one. Use Existing appears only when eligible resources exist. Selecting an existing database does not copy or reset its data.

For a Ghost Bucket, choose a new bucket for new application uploads, an eligible existing bucket for files the app already uses, or no bucket if object storage is unnecessary. Attaching a bucket does not move local uploads into it. The application must use the supplied storage settings.

Fill environment values and review

1. 1Supply the required environment values for each stage. Use the connection details belonging to that stage's selected database and bucket.
2. 2Check whether each value is needed during build, while running, or both. Secrets must not be exposed through frontend variables intended for visitors' browsers.
3. 3Use the included application address for initial testing, or connect a custom domain you control. Domain connection does not replace a successful deployment.
4. 4On Review, inspect every enabled stage, its source, commands, resource choices and environment settings.
5. 5Submit once and open Deployments. Wait for completion; a queued or building status is not yet a running application.
6. 6Open the app and test a real action, such as loading database-backed content. A successful homepage alone does not prove every feature works.

Expected result

Deployments shows a successful release for the intended commit, the app opens at its address, and its required database or storage action works. Record which stage you verified before sharing the address.