Deploy an app from a repository

1ClickOps takes the code in a repository, builds it on your server and puts it online. Your code goes from your git host straight to your server; it does not pass through us.

Which git hosts work

GitHub, GitLab, Bitbucket and Azure DevOps all work. How you sign in to 1ClickOps does not limit where your code can come from.

A public repository

Open your server’s Apps tab and start a new app. In the window titled Deploy New Application, fill in Git Repository URL with the repository’s https address, the branch, and an App Name (lowercase letters, numbers and hyphens only). Then deploy.

A private repository

Open Repositories. A private repository is read with an access key that is made on your own server. We never see the private half of it.

Under Add a repository, paste the repository’s SSH address and the branch to deploy.
Choose which server deploys it, and create the access key on that server.
Give the key read access. Do this for me works when your GitHub account is connected. Add the key myself instead shows the key to paste into your repository’s settings as a read-only deploy key; use that on GitLab, Bitbucket and Azure DevOps.
Press Test the connection.

Deploying again when you push

With GitHub connected, 1ClickOps tries to set this up when you deploy. On every host you can also do it by hand: under the repository, Deploy automatically whenever you push shows a webhook address and a secret. Paste both into your git host’s webhook settings and choose the push event only. They appear once the app has been deployed.

A push that arrives while a deploy is running is not lost. It waits, and is deployed next.
If the app has a staging copy, a push goes to staging and not to your live site. See Staging and “Push live”.

What is worked out for you

The language your app is written in: Node.js, Python, Go, PHP, Ruby or Java.
The commands that install what it needs and build it.
Whether it is a site made of plain files or a program that keeps running, and how to start it.

If your repository has its own Dockerfile, it is used as it is.

Before any visitor is sent to a new version, your server asks that version for its home page. A version that does not answer never goes live.

Changing how it is built

Open the app, then Settings. The card How this app is built has the folder to build from, the folder the build writes to, the install and build commands, the language version, and Settings needed while building. Leave a box empty to let 1ClickOps decide.

Save for the next build changes nothing that is running.
Save and rebuild rebuilds the version that is live now with the new settings.

Passwords do not belong in that card. Settings and secrets explains why.