Integrations

Basic Information

The first part of the Create Cloud Provider and Edit Cloud Provider dialog says which account this is and what CloudWady uses it for.

Provider and service type are chosen separately: pick the type for what this token will do. Without the White Label add-on, Domain and S3 Object Storage show a lock. Picking one opens the upgrade dialog and the type goes back to Hosting.

Saving the dialog stores the account. Nothing is created at the provider until something needs it, such as a new server. Maintainers and Admins of the owner namespace may change these fields.

API & Namespace Configuration

The second part of the dialog holds the credentials and says whose the account is.

Both keys are stored encrypted and are never shown on the card. On Edit, leave a key as it is to keep it, or type a new one to replace it. The plug button beside the token, Test Connection, makes a light call to the provider with the token in the field, or the stored one, and says whether it worked. It changes nothing.

With several namespaces selected in the switcher, Create and Edit ask you to pick one first. Admins of the owner namespace see an eye beside each key to read the stored value back; it asks for your password. A new token is used by the next run that needs the provider.

Add a domain

Create opens the Create Domain Provider dialog, in two parts:

Add the zone at Cloudflare or Hetzner first, and give the provider's token the right to edit its DNS. Saving adds the domain. Nothing is written at the DNS provider until an app, installer or URL needs a record.

Both fields can change until CloudWady has written one record in the zone. After that they are fixed, because the records are in that zone and were made with that account: add the other zone or account as a new domain. Sharing follows the cloud provider: lend the provider to a client namespace and its domains go with it (see API & Namespace Configuration).

The DNS records CloudWady writes

CloudWady writes A records that point at the server an app or installer runs on, with a time to live of five minutes:

• one wildcard record per environment, which covers the own address of every app in it;
• one wildcard record for the installers on a server, which covers their default addresses;
• one record for each custom URL whose name ends in one of your domains, for example shop.example.com under example.com.

The records are written by the run that deploys the app, installer or URL. They are removed when the URL is deleted or the app destroyed, unless another address still uses them. On Cloudflare a record is DNS only, not proxied, and it replaces any other record of the same name and type: move an existing record before you add the name in CloudWady.

For a name outside your domains, CloudWady writes nothing: point its DNS at the app's server yourself. A new record can take a few minutes to reach everyone.

The CloudWady GitHub App

The card at the top of Git Providers says whether the CloudWady GitHub App is installed for the namespace you are working in. Its badge and buttons follow its state:

When GitHub reports the installation, each repository it reaches is added to Git Repositories, owned by this namespace and shared with no one. A repository you add on GitHub later is added too; one you remove leaves the list. Fetch does the same on demand. Uninstalling the App on GitHub removes all its repositories from the list. The refresh button reads the state again.

With several namespaces selected in the switcher, the card does not show: pick one. Installing takes the Admin role; Update, Fetch, Complete and Reactivate take the Maintainer role. The App reads repositories, not GitHub packages.

Personal access tokens

Each token has a card: its name and type, Owner or Read-only, its state, its URL and API, and, for the owner, its Username. Add Token opens the Add Personal Access Token dialog:

Test signs in with the token and sets its state: Connected, Error, or Draft when something is missing. Once it is Connected, its type and URLs are fixed: add another token for another host. The token is stored encrypted and never shown again. On Edit, leave Password/Token empty to keep it.

Deleting a token cannot be undone. Repositories that read with it stop syncing until you give them another Git Account. Adding and deleting tokens take the Admin role; editing and testing one take the Maintainer role in its owner namespace.

Detect repositories

Repos, on a GitHub or GitLab token's card, opens Detect Repositories. It lists every repository the token can see, up to the first 500. Private marks a private one, and Added marks one already in Git Repositories, which you cannot pick again.

Type in the filter to narrow the list, switch on the repositories you want, or use Select all. Add Repositories (it counts your choice, as Add 3 Repositories) adds them to Git Repositories at once. Each is owned by the token's namespace, reads with this token and is shared with no one. Their branches appear after their first sync: click Fetch on a repository's card.

Nothing changes on your Git host. Detecting and adding repositories take the Admin role.

Repository

The Repository part of the Create Repository and Edit Repository dialog says where the code is and how CloudWady reads it.

Saving stores the repository. Its branches appear after its first sync: click Fetch on its card. A repository from the GitHub App reads through the App and needs no Git Account.

Once it has synced, its source and its owner, repository or project are fixed, because its branches and the apps on them come from that repository: add the other one as a new repository. Adding a repository takes the Admin role; editing one takes the Maintainer role in its owner namespace.

Access

The Access part of the repository dialog says who else may use it. Shared with namespaces lists them; empty, it reads Only the owner. A namespace listed here may see and deploy this repository, and nothing else of yours.

Use it to give a client namespace the code it runs. The client picks the repository for its projects and apps like one of its own, and CloudWady reads it with your Git Account; the client never sees your token. It may not change the repository.

The change applies when you save the dialog. Repositories from the GitHub App and from Detect repositories start shared with no one: you share them one at a time. Changing who it is shared with takes the Maintainer role in the owner namespace.