A provider is the infrastructure your nodes run on. When you request nodes, you choose a provider, and it supplies the machines. Different providers offer different kinds of machines and different settings (such as how much CPU and memory you can choose).
Choosing a provider
You pick a provider in the Where to run step of the request wizard (see Pools). Each provider is listed by its title and name. When you select one, the wizard shows the settings that provider offers — for example CPU, memory, and operating system — so you can describe the machine you want.
Managed providers versus self-hosted
Providers fall into two broad groups, and the difference changes how you add and remove nodes.
Managed providers
With a managed provider, ORC8R creates and destroys the machines for you. You simply set how many nodes you want (the pool size), and ORC8R keeps the pool at that number, adding or removing machines as needed. See Pools for how to scale.
Self-hosted
A self-hosted provider lets you connect machines you already own — your own servers or computers. Instead of ORC8R creating the machines, you install the ORC8R agent on each machine, and it joins the pool itself.
To add a self-hosted machine:
- Open the self-hosted pool and click Connect.
- Copy the one-time install command shown (there is one for Linux or macOS, and one for Windows).
- Run it on the machine you want to add.
The machine installs the agent, registers itself using a one-time token in the command, and appears in the pool. Because you add machines yourself, self-hosted pools do not have a size you set; they grow as you connect more machines. In the UI, self-hosted pools are labelled Self-hosted.
What a provider costs
Providers differ in where their price comes from, and it shows in how quickly the request wizard can quote you one.
- Some providers price each shape themselves. The wizard asks the provider what the machine you are describing costs and shows the answer, so changing a region or an instance type changes the estimate. If the provider cannot be reached, or has nothing to offer for that shape right now, the wizard says so and you can still submit — the pool waits for a price before it deploys.
- Others are priced by rates your ORC8R sets for them, and the estimate is worked out locally and immediately.
- A provider that nothing prices shows no price at all. That is not a price of zero; it means nobody is charging for it here.
The project's Resource Providers page
Open a project and go to Resource Providers to see which providers the project can use. This page is a read-only list; you do not add providers here. Providers are set up for you by whoever administers your ORC8R deployment.
For each provider the page shows its name, its network mode, and its visibility — which decides who can use it. The network mode says whether the provider isolates projects: vxlan and wireguard do, and none leaves networking to the machines' own network. Cloud providers are always wireguard: every cloud node joins its project's private network, SSH is closed on its public interfaces, and you reach it through its terminal in ORC8R. A cloud Linux node also has no public IPv4 address of its own: it sits on a private network with the provider's other nodes in the same location, and reaches the internet through that location's site gateway, a small machine the provider runs there that holds one stable public address. The operator can choose the gateway's instance type with the provider's gateway_plan setting; by default it is the cheapest one.
Vultr Windows nodes require a public IPv4 address, but ORC8R attaches a dedicated default-deny Vultr firewall before
boot and disables public IPv6. They join the same VPC and route IPv4 traffic through the site gateway. Their public
address is not an application endpoint; published services still use the gateway. The provider API key needs
firewall list, read and create permissions. Do not add inbound rules to the dedicated
*-windows-site-deny-inbound group: new Windows deployments refuse a group with rules.
Windows Server 2016 can run the agent and applications, but the interactive web terminal requires Windows Server 2019 or newer (ConPTY). On older Windows versions, use application tasks or the cloud console for diagnostics.
A cloud pool that exposes a port publicly gets one public IPv4 address of its own, its pool address, which the provider takes from the cloud and attaches to the location's site gateway: a floating IP on Hetzner, a reserved IP on Vultr. How many a provider can hold is its pool_ipv4_limit setting, 10 unless the operator names another, since neither cloud says; on Hetzner, floating IPs in the project that are not the provider's own pool addresses are taken off it. Hetzner bills a floating IP by the month, so one released by a pool is kept, unassigned, for the rest of the month it was paid for, and the next pool in that location that exposes a port takes it before a new one is bought; one nobody takes is deleted an hour before that month ends, so it is never billed another. Vultr bills by the hour, and a released address is deleted at once.
The visibility values are:
- Project — only this project.
- Organization — all projects in this organization.
- Global — all organizations.
If you have the right permissions you can change a provider's visibility from this page; otherwise it is shown for information only.