Integrations

Every provider is described in one place: which category it belongs to, which kind of resource it yields, which credentials it needs, and which of the seven capabilities it has. The panel, the platform and the agent all read that same description. Nothing in the product asks whether a system happens to be Proxmox.

That is why the tabs on an integration differ per provider. A test tab exists because the provider declares a connection test; an operating systems tab exists because the provider can hold templates; an import tab exists because the provider can list what it already runs. An absent tab is an absent capability, not a page that failed to load.

Hypervisor

Runs virtual machines and hands out the whole machine: cores, memory, disk, network. Which hypervisors are live and which are on the roadmap is shown on the integrations page.

Control panel

Runs web hosting accounts on a machine that is already up. It creates an account with a package, not an operating system. The integrations page labels each control panel live or roadmap.

Game panel

Runs game server containers, built from a recipe rather than from an operating system image. It sits next to control panels and not inside them, because almost nothing about the two is the same. The integrations page shows the game panels that are live.

Dedicated

Physical machines, installed over the network and operated out of band. Announced and not built.

Network

Switches and routers. Announced and not built, and it does not appear on the integrations page at all, because network devices have their own screens and do not count as a resource.

Seven capabilities decide what appears and what the platform is willing to send. A command that needs a capability the provider does not have is refused before it reaches your agent, with the reason named.

• Console: a live screen or terminal on the resource.
• Firewall: the platform can enforce which addresses a resource may use.
• Firewall rules: an ordered rule list you edit yourself, plus the firewall log.
• Hardware: disks and network cards you can add, resize and remove.
• Metrics: usage measurements, and therefore graphs.
• Operating systems: templates or images the platform can install from.
• Address assignment: Provibr decides which address the resource gets.

Adding an integration takes three steps: the kind of system, the connection, and the credentials. A category with nothing built behind it is visible but not selectable, so you can see what is coming without being able to pick it.

• You pick an agent as well as a provider. That agent is the one that will reach the system, so it has to be on a network that can.
• The name is yours. It is a label in the panel and nothing else reads it.
• The credentials are validated against the same rules the agent uses, then pushed to that agent and sealed in its vault. You stay on the page until the agent answers.
• If the agent refuses them, the reason is shown and your typed values stay put so a single typo does not cost you the whole form.

The credentials are never written to the platform's database. What is kept is the field names you filled in and the host and port, so the panel has something to show you and the audit trail has something to point at.

On the host they are encrypted with a key that is mixed with that machine's identity. Copying the vault and its key to another machine yields nothing. It does not protect against root on your own host. That host is yours, and so are the credentials.

Every provider that speaks HTTPS offers a fingerprint field. Fill it in and the agent will only accept the exact certificate you pinned, which is what makes a self-signed certificate on your own node safe to use. Take the fingerprint from the agent host, so you are pinning what the agent will actually see:

openssl s_client -connect <host>:<port> </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256

Active only means the agent accepted your credentials. It does not mean the integration is ready to hand out machines. The checklist above the tabs shows what is still missing and links straight to it.

• Credentials: delivered to the agent and accepted.
• Settings: the non-secret choices the provider needs, such as which node and which range of machine IDs. A provider with nothing to choose skips this step instead of showing it as undone.
• Installation method: whether machines are cloned from a template or installed over the network.
• Operating systems: at least one image linked, for the method you chose.

The test button queues a real call to your system, carried out by your agent, and shows what came back. What it reports differs per provider, because what a connection test can meaningfully say follows from that product's API.

• Proxmox: the version and the list of nodes with their online status.
• DirectAdmin: the panel version, the number of accounts, how many commands your login key is allowed to run, and whether the connection is encrypted. That last one only your agent can determine.
• Webmin: whether the Virtualmin module answers, how many hosting accounts and plans it has, and whether the certificate matches the fingerprint you filled in.
• Pterodactyl: the number of nodes and game servers, and whether the client key works. Without it there is no power control and no console, and you want to know that before your first start button rather than after.

Disabling is the safe middle step: the agent stops receiving commands for that integration and everything stays where it is. Re-enabling puts it back to active if the credentials were accepted before, and back to waiting-for-credentials otherwise, because whether they still work is something only a test can tell you.

The agent reports a code with parameters, not a sentence, so the panel can show you the reason in your own language. Where the other side said something itself (an HTTP body from your hypervisor, an error from your panel), that is quoted underneath, untranslated, because it is a quotation.

There is a second channel for the succeeded-but case. A panel that works over an unencrypted connection is not a failure, and it is not a status either, so it appears as a warning on the overview tab for as long as your agent keeps reporting it.