Your repo, connected.Your first release, understood.

Before connecting the repository.

Start with a repository you can identify and an application whose build you understand. Note the branch you want to deploy, the directory containing package.json, the package manager and any configuration needed by the build. If your app is a folder of plain HTML, its index.html is the useful starting point instead of a package manifest.

Run the app’s normal checks locally. For an npm project with a current lockfile, a useful baseline is the same clean install and build you expect a deployment service to perform:

npm ci
npm run build

These commands are examples for an npm project. Use the manager declared by your project; do not add a second lockfile just to follow the example. Commit the files that describe a reproducible build. Do not commit node_modules, local API credentials or a generated output directory unless your own workflow deliberately requires those artifacts.

Check runtime compatibility before granting repository access. New server-framework deployments become Workers. A Dockerfile, native executable or a provider-specific database binding is a separate requirement, not a feature inferred from a repository’s language badge. The hosting overview helps choose the right path.

Check the application directory before connecting.

A repository can hold several applications. The current GitHub connection selects a repository and branch, with bounded detection for a sole nested application. It does not save a separate service directory. Creating another project linked to that source does not choose a different folder.

For multiple apps or shared workspace packages, use the monorepo deployment guide before connecting. The archive Root directory picker repacks a subtree; it does not preserve dependencies outside that folder. Static output built with the complete workspace is a separate supported upload path.

Connect the repo in one setup flow.

1. Open the console and select New project → GitHub repository. For an existing project, use Overview → Deploy application / New deployment, or Deployments → New deployment.
2. Choose Connect GitHub if the account is not connected. Fortly requests GitHub’s repo scope, which includes read/write repository access; it uses that access to read code and manage deployment webhooks.
3. Search for the repository and select the intended branch. Review the source before continuing; a similarly named repository or a default branch can be the wrong one.
4. Leave Deploy on every push enabled if that is the workflow you want. Add configuration before confirming the release.

Automatic deployments require a webhook, and creating that webhook requires repository admin access. If the webhook cannot be installed, linking the source can still succeed. The console explains that automatic deployment was not set up; you can deploy explicitly while you resolve the repository permission.

Fortly deploys the exact commit pushed to the linked branch. Pushes to other branches, tag pushes and branch deletions do not create an automatic release. Treat branch selection as a release-policy decision, not just another input to click through.

Review variables before the first build.

Inventory which values are needed during installation or generation and which are read only when a request runs. Set them in deployment setup, or under Deployments → Variables. Runtime only, Build only and Build & runtime are different scopes with different exposure.

A missing public variable can leave a build green but the browser broken. A server token put in a public variable can grant far more authority than the page should have. Verify the identity and scope before pressing deploy, rather than treating every environment field as interchangeable.

Confirm the release, then verify the app.

Use Create and deploy for a new project or Deploy release for an existing one. Source acceptance is not publication. In the release view, follow Source, Build and Publish and read the output from the stage that is actually running. A build keeps going if you leave the page.

When the release becomes live, open its HTTPS address. Test a page and a route that represent the real application, not only the homepage. If it reads a table or uploads a file, exercise that path too. Use runtime logs for request-time errors and the release’s build output for installation or compilation errors.

1. Confirm the release shows the expected repository, branch and commit.
2. Open a direct nested URL and refresh it, especially for a client-side application.
3. Check one expected data request under the identity the application actually uses.
4. Confirm that the new request reaches the current release and produces the expected result.

A failed build does not replace an existing live release. For a first deployment, there is no earlier app to keep serving, so wait for a successful publication before expecting a working application. If the release fails, use the failure-stage guide to choose the next action.

Make the second release predictable.

With the repository linked and its webhook active, a push to the selected branch creates the next release. Keep the commit history meaningful and review changes that affect both code and data. The new build can fail without replacing the version visitors already use.

Keep a recovery plan broader than “roll the code back.” A release rollback restores application files and runtime output, not the contents of the database, stored files or environment values. Design a schema change so the previous application can still read the data it may encounter during a rollback.

Download diagnostic output you need to retain; log buffers and build records are bounded. Once the deployment path is stable, connect a custom domain and review the plan’s capacity. Those are useful next steps after you have verified a working release, not substitutes for that verification.