Completing Rack Configuration

Upon completing the Initial Rack Setup steps, the control plane services, including the web console, should be up and running.

In this final step of rack setup, you will configure the external IP addresses to be used by instances, create a user silo, and set up someone as the silo administrator with or without an identity provider (IdP).

1. Prerequisites

Before proceeding, confirm that the necessary networking preparations and identity provider setup have been completed.

The steps below require you to make use of the Oxide CLI. Download the appropriate binary from

2. Login Web Console

Open a session in the default browser of your workstation, log into the Oxide web console as the “recovery” user at https://recovery.sys.$oxideDomainName using the password specified during the initial rack setup process.

3. Create Device Token

Follow the instructions in Working with the API and CLI to create a device token. This token is linked to the recovery user and should only be used for managing rack setup.

4. Create a User Silo

The following information is required when creating a silo:



Must start with a letter and contain only lower-case letters, numbers, and dashes



Whether the silo should be included in silo listing queries (non-discoverable silos are accessible only by direct name or id reference)


There are two options


Users are authenticated with SAML using an external authentication provider


The system is the source of truth about users


If set, this group will be created during Silo creation and granted the "Silo Admin" role, applicable to saml_jit identity_mode only


Optional mapping of which Fleet roles are conferred by each Silo role, applicable to saml_jit identity_mode only


compute and storage resource limits


total number of virtual cpus of all running instances


total number of bytes of all running instances


total number of bytes of all disks provisioned


Initial TLS certificates to be used for the new Silo’s console and API endpoints; should be valid for the Silo’s DNS name which follows the convention $siloName.sys.$oxideDomainName or *.sys.$oxideDomainName for a wildcard certifcate





To create a silo, execute

oxide silo create --json-body silo.json

Here are some examples of the silo.json request payload based on its identity_mode

# identity_mode = saml_jit
# the mapped_fleet_roles enables silo admin group members to act as fleet admin
    "name": "$siloName",
    "description": "$siloDescription",
    "discoverable": true,
    "identity_mode": "saml_jit",
    "admin_group_name": "$idpAdminGroup",
    "mapped_fleet_roles": {
      "admin": [
    "quotas": {
        "cpus": 18,
        "memory": 8589934592,
        "storage": 107374182400
    "tls_certificates": [{
        "name": "initial-install-cert",
        "description": "wildcard certificate",
        "service": "external_api",
        "cert": "$fullCertChainPemBlob",
        "key": "$privateKeyPemBlob"

# identity_mode = local_user
    "name": "$siloName",
    "description": "$siloDescription",
    "discoverable": true,
    "identity_mode": "local_only",
    "quotas": {
        "cpus": 18,
        "memory": 8589934592,
        "storage": 107374182400
    "tls_certificates": [{
        "name": "initial-install-cert",
        "description": "wildcard certificate",
        "service": "external_api",
        "cert": "$fullCertChainPemBlob",
        "key": "$privateKeyPemBlob"

5. Configure Silo Identity Provider

Perform this step only if your silo uses saml_jit for authentication.

The following attributes are required when configuring an identity provider:



Name of the IdP realm backing the Oxide silo


IdP service description



IdP service metadata source, values allowed are base64_encoded_xml or url


specify this when type=base64_encoded_xml, e.g. $(curl -sq | base64 -w0)


specify this when type=url, e.g.


IdP realm root URL


IdP client or app ID


Endpoint on the Oxide Console to which the identity provider will redirect with its authentication response


Single logout endpoint, may be set to the same value as ACS URL (i.e. taking user back to the Oxide Console login page)


Email address of identity provider support contact (Note: Oxide rack does not generate email notifications at this time)


Used by the client for signing the login request




The custom attribute that captures group name information (in the form of a comma-separated list) that is returned as part of the SAML access token response. The information will be used to auto-create IAM groups and assign the user to those groups.

To configure the IdP for the silo created above, execute one of the following commands depending on how you want to specify the IdP metadata

oxide silo idp saml create --silo $siloName --json-body idp.json --metadata-value $base64EncodedMetadataXml


oxide silo idp saml create --silo $siloName --json-body idp.json --metadata-url $idpMetadataUrl

Here is a sample request payload for the idp.json file

  "name": "example",
  "description": "Oxide Silo SAML IdP",
  "idp_entity_id": "",
  "sp_client_id": "example-oxide",
  "idp_metadata_source": {
     "type": "base64_encoded_xml",
     "data": ""
  "acs_url": "https://$$siloName/saml/example",
  "slo_url": "https://$$siloName/saml/example",
  "technical_contact_email": "",
  "signing_keypair": {
     "public_cert": "$base64EncodedDer",
     "private_key": "$base64EncodedDer"
  "group_attribute_name": "admins"
If the silo or the identity provider is incorrectly configured, you can log into the Recovery Silo to delete the silo and recreate it with the correct configuration.

6. Create Local Users

Perform this step only if your silo uses local_user for authentication.

To create the first user in the silo and grant this user administrator access, execute

# create user
oxide silo idp local user create --silo $siloName --json-body user.json

# grant silo admin role
oxide silo policy update --silo $siloName --json-body policy.json

# grant fleet admin role
oxide system policy update --json-body policy.json

Here is how the user.json and policy.json payloads should look like

# user.json
  "external_id": "$loginname",
  "password": {
    "mode": "password",
    "value": "$passwordValue"

# policy.json
  "role_assignments": [{
    "identity_id": "$idReturnedFromCreateUser",
    "identity_type": "silo_user",
    "role_name": "admin"

7. Test User Login

On a separate browser tab or window, log into the newly created silo at https://$siloName.sys.$oxideDomainName, either as yourself via the identity provider or as the local administrator using password authentication.

In the case of IdP integration, if the admin group attributes are configured correctly, your account should be imported into the rack with the silo “admin” role automatically granted. You can confirm your group assignments in the Profile page under Settings.

Before logging in, ensure your account in the IdP is part of the group specified in the admin_group_name of the silo.

8. Create and configure IP Pool

IP pools are logical abstractions for external IP address allocation. Each silo may have one or more IP pools associated with it and must have one of them set as the default. When a VM instance is provisioned, IP addresses will be automatically assigned from the IP pool specified in the request as long as the pool is linked to the silo.

Follow these steps to create your first IP pool and link it to the new silo:

# create the IP pool
oxide ip-pool create --pool $poolName --description $poolDescription

# insert an address range into the new IP pool
oxide ip-pool range add --pool $poolName --first $firstIpInRange --last $lastIpInRange

# link the pool to your new silo and make it the default
oxide ip-pool silo link --pool $poolName --silo $siloName --is-default true

An IP pool may include one or multiple address ranges and they do not need to be contiguous. The number of IP addresses to allocate to each pool will depend on the expected number of VM instances using it. You can always start with a small IP range and add more address ranges later on.

Each VM is assigned a quarter of an external IP address for NAT-ing egress traffic whether it has an ephemeral or floating IP or not. When sizing the IP pool capacity, your estimations will have to include the NAT usage as well.

Additional context and considerations about the data network are available in the Network Preparations and IP Pool Management guides.

Last updated