Panel Links

What a panel link is

A panel link joins two FluxBilling installations so that one of them can create and run virtual machines and game servers on hardware the other owns. The installation that owns the hypervisors decides exactly which of them the other may use; the installation that borrows them sells and operates on that capacity as if it were its own.

Two rules never change, and they explain everything else about how a link behaves:

• Hardware has exactly one owner. Only the owning installation runs the provisioning agent on a node. The other installation never installs a second agent and never talks to the hypervisor directly — every instruction it issues travels over the link and is checked again on the owner's side.
• Every workload is attributed. Looking at a machine on the owning installation, an operator can always see which installation sold it and which service it belongs to there.

The usual reason to build one is a company running more than one panel — separate brands, separate markets, separate legal entities — on a single set of hypervisors. It also works between two independent companies that have agreed to share capacity.

A link is not the reseller programme

The two features look adjacent and do completely different jobs. A panel link shares hardware. It carries no catalogue, no prices, no orders and no invoices — nothing about money crosses it in either direction. The reseller programme is the opposite: it shares a catalogue at wholesale prices, and the services stay on the seller's own hardware. The two can be used between the same pair of installations without interfering with each other; pick whichever matches the arrangement.

Reaching the page

Open VPS in the admin panel and select Panel Links in the tab strip at the top of the VPS module, between Game Hosting and Jobs. Both halves of a link are managed from this one page — the hardware you lend out and the hardware you borrow. It is always available and does not depend on any module being switched on. Older bookmarks to the previous location under Settings still open it.

Viewing the page needs the settings view permission; generating a key, redeeming one, revoking or changing what is shared needs the settings edit permission. Without the view permission the page explains what is missing; without the edit permission the controls are simply absent.

At the top, a card reads Peers see this panel as followed by the name other installations display for yours, the address they reach you at (with a copy control), and the date your identity certificate is valid until. That name travels with your licence rather than being typed in locally, which is why the other side can trust it. Refresh identity re-reads it.

Note: If the installation has not received its identity yet, the page says so and both Generate link key and Add panel are unavailable. Check your licence status first, then use Refresh identity. The page also warns when the identity certificate is within a week of lapsing or has lapsed; it normally renews itself, and Refresh identity forces it.

Below that, two lists sit side by side. Peers using this panel's hardware holds the installations allowed to build on your hypervisors and game nodes, with a count of how many are active, waiting to pair, expired or revoked. Fleets this panel may use holds the installations whose hardware you borrow. Revoked entries in either list are folded away under a “revoked links” line so the working rows stay uncluttered. Until the first link exists, a short three-step explainer sits above the lists.

Proposing a link

The installation that owns the hardware starts. On its own Panel Links page:

1. Select Generate link key. A dialog asks for an optional note — who the key is for, such as the name of the other company or brand. Only your installation ever sees the note; it is never sent to the other side and it is not the name the other side is shown. It exists so that two keys generated on the same day can be told apart, and it stays under the peer's real name once the key has been redeemed.
2. The key is shown in a dialog, masked by default. Use Copy to put it on the clipboard or Reveal to read it. It begins with flxlink_ and carries the address of the installation that issued it, so the other side has nothing else to fill in. The dialog also lists the three steps that follow.
3. Send it to the operator of the other installation over a channel you trust.

A new row appears at once with the status Waiting to pair, titled with your note (or Unused link key if you left the note empty), showing when the key was generated and the date until which it can be used.

Warning: Treat a link key like a password. Anyone holding it can pair with your installation. They still reach no hardware at all until you tick specific clusters for them — but a key that leaks should be rotated.

A key that nobody redeems expires seven days after it was generated. An expired row reads Key expired and offers New key, which issues a fresh key with a fresh seven-day deadline; the old one stopped working the moment it expired. A waiting key can be looked at again at any time with Show link key, and its row menu offers Rotate key, Edit note and Discard key. Because nobody has used it, discarding it breaks nothing.

While a key is out waiting, the page re-checks by itself every few seconds, so the row turns Active on its own when the other side redeems it.

Accepting a link

The installation that borrows the hardware redeems the key on its own Panel Links page:

1. Select Add panel.
2. Paste the key into the Link key field and select Link panel. A confirmation names the installation you are now linked to, and it appears under Fleets this panel may use with the status Active and the date it was paired.
3. Select Sync on that row. This pulls in the clusters and game nodes the other side has ticked for you; a message reports how many arrived. The row then carries a Mirrored chip counting the clusters, machines and game nodes it currently provides, which opens the clusters list.

Redeeming a key is the whole of the consumer-side setup — there is no address to type and no credential to store by hand, because the key carries both. If Sync reports nothing, the owner has not ticked any hardware for you yet; ask them, then sync again. The Connect shared clusters control on the VPS clusters page still re-pulls for existing connections, including ones set up under the older reseller arrangement.

On the owner's side the same link now appears under Peers using this panel's hardware, with the status Active, the name the other installation carries on its licence, and the note the owner wrote when generating the key.

Choosing what to share

Pairing on its own grants nothing. On the owner's Panel Links page, select Sharing on the link's row to open What this peer may use. The button is highlighted, and the row carries a Nothing shared yet reminder, while a paired installation has been granted nothing at all.

The dialog has two independent halves, each with a main switch and a checklist:

The sharing dialog

Control	What it does
Share VPS clusters	Turns virtual-machine sharing on for this link and reveals the cluster list. Only the clusters you tick are visible to the other side. Select all and Clear tick or untick the whole list.
Full VM management	Off by default. With it off, the other installation can power, resize and delete the machines it created. With it on, it can also open a console, reinstall the operating system, reset the root password, take and restore snapshots, set resource ceilings, attach boot media, read guest details and add or release addresses — the same controls your own panel has, on its own machines only.
Share game nodes	The same arrangement for game hosting: a switch and a checklist of nodes.
Full server management	Off by default. With it off, the other installation can create, read, power and end game servers it owns. With it on, it can also open the console, use the file manager, rotate transfer credentials, take and restore backups, install modifications and set schedules.

Beside every cluster and node in the checklists, the dialog shows how many of this peer's machines or game servers are running on it right now — 2 of their VMs here. That figure is what makes the next rule visible before it bites.

Warning: Unticking hardware the peer still uses does not stop its machines. It takes away the peer's ability to see, power, resize or reinstall them — its customers lose control of servers they are paying for, from another panel, without warning. So Save sharing stops and asks Take this hardware away from the peer?, listing exactly the clusters and nodes involved and the machines on each. Remove anyway proceeds; Cancel returns to the dialog so you can tick the hardware back on. Agree the change with the other operator first.

Select Save sharing to apply. Turning a main switch off clears its checklist, so a switched-off share never leaves a stale list behind.

Only hardware this installation actually owns can be offered. Clusters and nodes it is itself borrowing from someone else are excluded from the lists — capacity is never re-shared onward. If a list is empty, register a cluster or a node first.

Once saved, the link's row carries badges showing how many clusters and how many nodes it may reach; a shield on a badge means full management has been granted for that product. The two grants are deliberately separate decisions: letting another installation build machines on your hardware is one question, and letting it open a console on a running machine or roll it back to a snapshot is a different one.

What each side sees and controls

The installation that owns the hardware

The owner keeps everything. Wherever a machine appears — the instance list, the machine table on a cluster's page, the instance detail — a machine sold by a linked installation is labelled sold by that installation, together with the service reference it carries there and that service's status. Local machines show their own customer instead. The instance list has a used by filter (any panel, this panel only, or one linked installation at a time), and on the Panel Links page each peer's row carries a Built here chip counting its machines and game servers on your hardware; the chip opens the instance list already filtered to that installation.

Everything about the hardware itself stays with the owner: hypervisor discovery and imports, node maintenance and decommissioning, moving a machine between the owner's own nodes, and cluster settings. Host metrics are collected and shown only on the owner's side.

The installation that borrows it

A borrowed cluster appears in VPS → Clusters with the status Shared, and its pages carry a banner naming the connection and explaining that the hardware belongs to the other installation. Machines created on it are managed from here, but the cluster-level tools are greyed out with Settings live on the owner panel.

Per machine, the borrowing side can always start, shut down, reboot and force off, resize, delete, edit its own notes and tags, and read the addresses assigned to it. The controls listed under Full VM management above appear only when the owner granted them; without the grant they are greyed out with a tooltip saying so. Two operations are never available on borrowed hardware because they move a machine between the owner's own nodes: migrating it and converting it to a different hypervisor stack.

The link's own row on Panel Links is where the health of the arrangement shows:

• Sync re-reads what the owner currently offers — clusters and game nodes alike — and refreshes the state of the machines on them. Run it after either side changes what is shared.
• A Sync failing chip means the last call to the owner did not succeed; the error is written out underneath as Last sync error. An Access refused chip means the owner no longer accepts this installation's key — it has been rotated or the link revoked on their side.
• Call history in the row menu lists every call this installation made over the link, newest first, with the result and how long it took. Only this side's calls are recorded; the owner keeps its own log.
• Edit note attaches a private note to the row, exactly as on the owner's side.
• Stop using this fleet ends the arrangement from your side. The mirrored clusters and the machines your customers have on them stay listed, but every action on them is refused. Pasting the same key under Add panel reconnects, unless the owner has rotated it since.

Three banners on a borrowed cluster are worth recognising:

• The owner reports this cluster as not active. Creating machines is paused until the owner's cluster is healthy again. Existing machines keep running.
• The owner panel no longer shares this cluster. The cluster was un-ticked on the other side. Existing records are kept and marked, but no new machines can be created. Re-share it on the owner's side, then use Sync.
• Any error the link itself reported is shown on the link's row on the Panel Links page.

Isolation

A linked installation can see and touch only the machines it created itself. Machines belonging to the owner, and machines belonging to any other linked installation, are not merely refused — they are invisible, answering as though they do not exist. Nothing about the other side's customers crosses the link either: the owner records which installation sold a machine and the service reference there, and nothing else. No customer name, no email, no account.

Rotating and revoking

Both controls sit in the row menu on the owner's Panel Links page.

• Rotate key issues a new key. If the link is already paired, the other side loses access immediately and stays disconnected until you send them the new key; their existing machines keep running throughout, and the confirmation shows how many there are. If nobody has redeemed the old key yet, nothing breaks. On an expired key the same control reads New key.
• Revoke link ends the arrangement. The other installation loses access to your hardware immediately. Machines it already created keep running and stay attributed to it — nothing is destroyed — but it can no longer manage them from its panel. The confirmation counts the machines and game servers that installation currently has on your hardware. On an unpaired key the same control reads Discard key.

Warning: Revoking is not a way to reclaim capacity. The machines stay where they are and keep consuming resources; their customers keep using them, and nobody on either side can power them off from a panel until the link is restored. Agree an exit with the other operator before you revoke.

Pricing and billing across a link

Nothing financial crosses a panel link. There is no wholesale price, no markup, no catalogue synchronisation and no order forwarding. Each installation keeps its own products, its own prices, its own invoices and its own customers, and neither can see the other's.

In practice that means:

• The borrowing installation creates its own VPS plans and its own products, prices them however it likes, and targets the plans at the shared cluster the same way it would target one of its own. Its customers are billed by it, on its documents, in its currency.
• The owning installation bills nothing for the capacity through the platform. Whatever the two companies have agreed — a flat fee, a per-machine rate, an internal transfer between two arms of one company — is settled outside the platform. The owner's per-installation machine counts are the figures to reconcile against.
• If you do want the platform to price and invoice the capacity automatically, that is the reseller programme rather than a panel link: it carries wholesale prices, orders, documents and events. See Reseller API and Reseller Program.

One thing does travel with a machine: the resource ceilings its plan sets — processor share, network rates in and out, disk throughput and operations. They are applied automatically once the machine finishes building, and on borrowed hardware the selling side sends them to the owner, which validates and applies them on its own hypervisor. Because that is a management operation, it needs Full VM management on the link. Grant it if the plans sold across the link rely on those ceilings.

What the customer of the selling side experiences

Nothing unusual, which is the point.

• They browse the selling company's catalogue, order a plan and pay the selling company's invoice, exactly as with any other product. See Placing an Order.
• The machine is built on the other company's hardware, and appears in their client portal as an ordinary VPS or game server — hostname, addresses, specifications, statistics.
• Which buttons they get follows the grant the two operators agreed. Power controls are always there. Console, reinstall, password reset and snapshots reach them only where the owner granted full management and the selling side offers those controls on the product.
• Nothing identifies the other company. The customer sees the location the selling side has named for the cluster; there is no other trace of who owns the hardware.
• Support stays with the selling company. Their customer opens a ticket with them; if the hardware itself is the problem, it is the two operators who talk to each other.

What can go wrong

• The link key is refused. It has expired (seven days after it was generated), it has been rotated or discarded on the owner's side since it was issued, or it was truncated when it was copied. Ask for a fresh one.
• Neither installation can generate or redeem a key. One of them has not received its identity, or its identity certificate has lapsed. Check its licence status and use Refresh identity.
• The link is Active but no clusters arrive. Nothing has been ticked in the sharing dialog on the owner's side, or the change has not been picked up yet — select Sync on the link's row.
• There is no Sharing button on a row. The key is still Waiting to pair — the row offers Show link key instead until somebody redeems it. Sharing appears the moment the link turns Active.
• Save sharing asks for confirmation. You are removing hardware the peer still has machines on. Tick it back on, or accept that the peer loses control of those machines.
• A cluster is missing from the sharing checklist. Only hardware this installation owns can be offered; anything it is itself borrowing is excluded, and capacity is never passed on a second time.
• Console, reinstall or snapshots are greyed out on the borrowing side. Full management has not been granted for that link. The owner turns it on in the sharing dialog.
• New machines are refused, existing ones are fine. The owner's cluster is not active, or it has been un-shared. The banner on the cluster says which.
• A fleet you use shows Access refused. The owner rotated the key or revoked the link. Ask for a new key and add the panel again; if the arrangement has ended, use Stop using this fleet.
• A machine on the owner's side shows no owner name. The link has been removed since the machine was created. The record still shows that it belongs to another installation, so it is never mistaken for a local one.

Related articles

• VPS Clusters — registering hardware, and where borrowed clusters show up.
• VPS Plans — targeting a sellable plan at a cluster.
• VPS Instances — the machine list, its attribution and its per-machine controls.
• Game Nodes — the game-hosting equivalent of a cluster.
• Reseller API — the alternative arrangement, where prices and orders do cross.