# Payments
Source: https://rackdog.com/docs/billing/payments

Manage payment methods and invoices

Rackdog accepts payment by credit card. Each organization keeps a default card on file, which is charged automatically for new purchases and recurring subscriptions.

## Adding a payment method

Before you can add a card, you'll need an [organization](/docs/organizations/overview).

1. Go to `https://metal.rackdog.com/<organization_id>/billing`.
2. Click **+ Add New Method**.
3. Enter your card details and save.

The first card you add is set as the organization's default payment method. You can add additional cards at any time and change the default from the same page.

## Missed payments

A payment can fail for a number of reasons, such as a card being removed, declined, or expired. When that happens, we'll notify your organization that an invoice is outstanding.

If the invoice remains unpaid:

* **After 5 days**, the affected resources are suspended until payment is received.
* **After 14 days**, the resources are terminated. For servers, this means the disk is wiped and cannot be recovered.

To avoid interruption, keep a valid default card on file and settle outstanding invoices promptly.


# Subscriptions
Source: https://rackdog.com/docs/billing/subscriptions

Manage your Rackdog subscription

Rackdog resources are billed on a recurring subscription. How a subscription is prorated depends on the resource type.

## Servers

Server subscriptions begin the moment the server is provisioned. Your organization is charged the full monthly cost upfront, and billed again on the same day each month thereafter.

For example, a server ordered on March 4th is charged immediately, then again on April 4th, May 4th, and so on.

## IPAM

Additional IP allocations bill on a calendar-month cycle. The initial charge is prorated from the allocation date through the end of the current month; subsequent charges are billed on the 1st of each month.

For example, an additional `/29` allocated on April 10th is prorated from April 10th through May 1st. From then on, it's billed on the 1st of every month.

## Cancellations

To cancel a subscription (server, IPAM, or otherwise), terminate the resource from the dashboard or via the API. Termination is immediate: the resource is removed from your organization and billing stops right away.


# Additional IPs
Source: https://rackdog.com/docs/features/additional-ips

Allocate and route extra IPv4 and IPv6 address space to your servers

Rackdog lets you allocate additional IP address space and route it directly to a specific server. The allocation is statically routed on the network switch, so traffic for any address in the block is delivered to the server without extra configuration on the gateway side.

Billing for additional IPs is prorated to the first of the following month and then billed monthly. See [Subscriptions](/docs/billing/subscriptions) for details.

## How it works

1. Provision a server.
2. Request an IP allocation via the API, pointing it at that server.
3. Rackdog installs a static route on the switch for the block.
4. You configure the addresses on the server itself.

Rackdog handles the routing. You handle how the IPs get used on the box.

## IPv4 allocations

Block sizes: `/30`, `/29`, `/28`, or `/27`. The hard cap per allocation is **32 IPv4 addresses** (`/27`); larger requests require approval.

## IPv6 allocations

IPv6 support depends on the server. Use the API to list your servers and check which ones support IPv6 allocations. Only `/64` blocks are supported.

## Ordering

Once you have a server running, call the IP allocation API with the server ID and the block size you want (IPv4 or IPv6). Check allocation status via the API; once it's active, the block is routed to your server. Dashboard support is on the way.

## Routing

All addresses in the allocation are statically routed from the switch straight to your server. That means you don't need to add extra routes inside the OS or configure a custom gateway: the network will deliver traffic for the block, and you just need to assign the addresses on the server's interface.

## Configuring the OS

Rackdog doesn't configure the addresses inside the operating system. After the allocation is active, assign them on your server.

### Ubuntu / Netplan (IPv4)

```yaml theme={null}
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 203.0.113.10/32
        - 203.0.113.11/32
```

Apply:

```bash theme={null}
sudo netplan apply
```

### Ubuntu / Netplan (IPv6)

```yaml theme={null}
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 2602:abcd:1234::1/64
```

## Things to know

* IP blocks are routed to a specific server, but you can move an allocation to a different server at any time.
* If the target server is deleted, the routing goes away, but the allocation itself stays on your account and continues to bill until you either reassign it to another server or cancel it.
* You can use any address in the allocated range.
* You're responsible for assigning the addresses on the server and pointing your services at them.

## Common use cases

Additional IPs show up most often for:

* Hosting multiple services on their own addresses.
* Load-balancing or failover setups.
* Multi-tenant applications.
* Reverse proxies and ingress systems.
* Running a hypervisor like Proxmox on the server and assigning public IPs directly to individual VMs.

## Good habits

* Assign addresses explicitly so you're not paying for unused allocations.
* Keep internal documentation of which IP maps to which service.
* Validate OS config after applying changes — a typo in Netplan is easy to miss.


# iPXE
Source: https://rackdog.com/docs/features/ipxe

Customize server provisioning with iPXE chainloading.

Rackdog supports iPXE chainloading so you can control how a server boots. Instead of using a stock OS install, point Rackdog at your own iPXE script and take over the boot and provisioning process.

To use it, select the **Custom iPXE** OS option when [ordering a server](/docs/quickstart) and provide your iPXE URL.

## How it works

When you provide an iPXE URL, Rackdog wraps it in a chainloading script that runs at boot:

```ipxe theme={null}
#!ipxe
dhcp || echo "dhcp failed (continuing)"

echo Booting user chain: <your-url>
chain --autofree <your-url> || goto chain_failed

:chain_failed
echo Chain failed. Dropping to shell...
shell
```

Your URL is substituted into this template at provision time.

## What you provide

Supply a publicly reachable URL that returns a valid iPXE script, for example:

```
https://example.com/boot.ipxe
```

Some flows also accept an inline script body in place of a URL.

## Example script

A minimal script that boots a Linux kernel:

```ipxe theme={null}
#!ipxe
kernel https://boot.example.com/vmlinuz initrd=initrd.img
initrd https://boot.example.com/initrd.img
boot
```

## When to use it

Reach for iPXE when you need a custom OS image, a preconfigured environment, integration with your own provisioning system, ephemeral or stateless workloads, or just direct control over the boot process. For standard images and faster setup, stick with normal provisioning.

## Requirements

* The iPXE URL must be reachable from the Rackdog network.
* The script must be valid iPXE syntax.
* Every asset referenced by the script (kernel, initrd, and so on) must be reachable from the server at boot.

## What happens on failure

If chainloading fails, the server prints the error and drops into the iPXE shell. From there you can debug interactively:

```ipxe theme={null}
ifstat                              # check network state
dhcp                                # retry DHCP
chain https://example.com/boot.ipxe # try a chain by hand
```

## Good habits

* Host your scripts on infrastructure you trust to be available when servers boot.
* Keep scripts short and deterministic so boots are predictable.
* Version or log your boot scripts so you can trace what a server ran.
* Validate a script locally before pointing production servers at it.


# Provisioning Scripts
Source: https://rackdog.com/docs/features/provisioning-scripts

Run your own setup scripts during server provisioning

Provisioning scripts let you save small setup scripts in your Rackdog organization and run them when a server is installed or reinstalled.
Use them for setups you repeat often: installing packages, adding agents, creating users, writing config, or registering the server with your own tooling.

Scripts are saved at the organization level. When you select a script for a server, Rackdog copies its content into that provisioning run.
If you edit or delete the saved script later, already queued installs will still use the copied version.

## How it works

1. Create a saved script.
2. Select one or more scripts when ordering, provisioning, or reinstalling a server.
3. Rackdog records the selected scripts and their order for that install.
4. On supported Linux and Windows templates, each script runs on first boot.

If no scripts are selected, provisioning continues normally.

## Requirements

* Linux scripts use Bash by default. To use another interpreter, start the script with `#!/usr/bin/python3`.
* Windows scripts run with PowerShell.
* Script content can be up to 1500 characters.
* Script names can be up to 100 characters.
* Linux scripts run as root. Windows scripts run as Administrator.
* Creating, updating, or deleting scripts requires organization admin access.
* Selecting the same script twice in one request is rejected.
* Scripts do not run on Custom iPXE installs.

## Create a script

Use the public API to create a saved script:

```http theme={null}
POST /v1/servers/provisioning-scripts
```

```json theme={null}
{
  "name": "base packages",
  "description": "Install packages we expect on every server",
  "content": "#!/usr/bin/env bash\nset -e\napt-get update\napt-get install -y htop curl"
}
```

The response includes the script ID and `contentSha256`. Use the ID when selecting the script for a server.

## Select scripts for an install

Add `provisioningScripts` to an order, provisioning, or reinstall request:

```json theme={null}
{
  "provisioningScripts": [
    {
      "scriptId": "00000000-0000-0000-0000-000000000000"
    },
    {
      "scriptId": "11111111-1111-1111-1111-111111111111"
    }
  ]
}
```

Scripts run in the order listed in `provisioningScripts`.
If a script exits non-zero, Rackdog stops running the remaining scripts and does not roll the install back.

Script output and errors are written to the server:

* Linux: `/var/log/rackdog/provisioning.log`
* Windows: `C:\ProgramData\Rackdog\provisioning.log`

## Good habits

* Provisioning scripts are best for small bootstrap tasks.
  * For larger setup flows, use a provisioning script to set up your preferred configuration management tool.
* Avoid putting long-lived secrets directly in script content.
* Test on a non-production server before using a script across a fleet.


# SSH Keys
Source: https://rackdog.com/docs/features/ssh-keys

Generate an SSH key and use it to access your Rackdog servers

SSH keys let you log in to your servers without passwords. Rackdog accepts a public key at provision time and installs it on the server so you can connect as soon as it's ready.

## Generate a key

On your local machine, run:

```bash theme={null}
ssh-keygen -t ed25519 -C "your_email@example.com"
```

This creates a private key (keep it on your machine) and a public key that you'll paste into Rackdog.

## Find your public key

```bash theme={null}
cat ~/.ssh/id_ed25519.pub
```

Copy the output. That's what you'll paste into the dashboard.

## Add the key to your organization

SSH keys are stored at the organization level, so add the key once and reuse it across servers.

1. In the dashboard, go to `https://metal.rackdog.com/<organization_id>/sshkeys`.
2. Click to add a new key, give it a name, and paste in your public key.
3. Save.

## Select the key when provisioning

During server provisioning, pick the key you just added from the **SSH key** selector. Rackdog will install it on the server automatically so you can log in as soon as provisioning finishes.

## Connect to the server

Once the server is ready, grab its IP from the dashboard and connect. The username depends on the OS you provisioned:

| OS            | Username        |
| ------------- | --------------- |
| Ubuntu        | `ubuntu`        |
| Debian        | `debian`        |
| CentOS        | `centos`        |
| Fedora        | `fedora`        |
| Rocky Linux   | `rocky`         |
| AlmaLinux     | `almalinux`     |
| Windows       | `Administrator` |
| Anything else | `root`          |

For example, on an Ubuntu server:

```bash theme={null}
ssh ubuntu@YOUR_SERVER_IP
```

## Good habits

* Keep the private key on your own machine and don't share it.
* Use a passphrase when you generate the key.
* Rotate keys periodically, especially if a machine holding one is lost or decommissioned.
* Disable password-based SSH on the server once key access is working (set `PasswordAuthentication no` in `/etc/ssh/sshd_config` and reload `sshd`).


# VLANs
Source: https://rackdog.com/docs/features/vlans

Create private Layer 2 networks between your servers

VLANs let you build a private Layer 2 network between your servers over their secondary (non-public) network interfaces. Servers on the same VLAN can talk to each other directly, without the traffic ever touching the public internet.

## How it works

VLANs are defined logically first and only materialize on the network when they're actually needed:

1. You create a VLAN (via the API or dashboard).
2. You attach servers to it.
3. Once **two or more** servers are attached, Rackdog allocates a real VLAN on the switch and connects the servers to it.
4. The servers can now reach each other over their private interfaces.

A VLAN with a single server attached exists in your account but has no underlying network: there's no one to talk to, so nothing gets provisioned on the switch until a second server joins.

## Lifecycle behavior

* **Server removal.** Deleting a server automatically detaches it from any VLAN.
* **Down to one server.** The VLAN stays allocated internally, but there's no connectivity until another server joins.
* **Down to zero servers.** The underlying network is cleaned up. The VLAN still exists from your perspective and can be reused when you attach servers again.

## Creating a VLAN

VLANs are managed through the API today: create the VLAN, attach servers, and manage membership there. Dashboard support is on the way.

Not every server supports VLAN networking. Use the API to list VLAN-capable servers before attaching.

## Private networking

VLAN traffic flows over each server's secondary network interface. The primary interface handles public networking and is not used for VLAN traffic.

## IP configuration

Rackdog does not hand out IP addresses inside your VLAN. You pick the subnet and configure addresses on each server yourself.

### Example (Ubuntu / Netplan)

**Server 1:**

```
10.10.10.1/24
```

**Server 2:**

```
10.10.10.2/24
```

Apply the Netplan config on both servers and they'll be able to reach each other over the VLAN.

## Things to know

* VLANs operate at Layer 2 only. There's no routing by default.
* IP addressing, subnet design, and any routing between VLANs are your responsibility. If you need to connect multiple VLANs, use a dedicated server as the router.

## A typical workflow

1. Create a VLAN via the API.
2. Attach two or more servers.
3. Configure private IPs on each server.
4. Verify with a ping between them.

## Good habits

* Attach at least two servers so the VLAN actually activates.
* Use consistent subnetting across servers in the same VLAN.
* Keep private addressing organized, for example by environment or service.

## When to use VLANs

Reach for a VLAN when you want private traffic between servers, isolation from the public internet, or a custom topology across your fleet.


# Welcome to Rackdog
Source: https://rackdog.com/docs/index

Bare metal infrastructure and programmable networking for modern workloads.

Rackdog is a bare metal platform with programmable networking. You get dedicated hardware, direct control over your servers and IPs, and an API that drives all of it.

## What you can do

* Provision dedicated bare metal servers
* Configure private networking
* Isolate environments with VLANs
* Manage IPs, servers, and VLANs through a single API

## How Rackdog works

Everything runs on dedicated hardware, so there are no shared CPUs or noisy neighbors. The platform exposes infrastructure primitives directly (servers, networks, IPs) rather than hiding them behind abstractions, and every resource you can create in the dashboard is also available through the API.

## Getting started

1. Create an account and [organization](/docs/organizations/overview).
2. Add a [payment method](/docs/billing/payments).
3. Provision your first server.

From there, head to the [Quickstart](/docs/quickstart) to walk through it end to end.

## Who it's for

Rackdog is built for teams that run their own infrastructure: engineering groups that want dedicated performance, companies with specific networking or compliance needs, and anyone who'd rather work with real hardware than a leaky abstraction over it.

## Need help?

Reach out to support for onboarding help or anything you can't find in the docs.


# Overview
Source: https://rackdog.com/docs/organizations/overview

What organizations are and how to create one

An organization is the top-level container for your Rackdog resources. Servers, IP allocations, payment methods, and invoices all belong to an organization, and every user accesses Rackdog through one.

## Creating an organization

1. Sign in to the [Rackdog dashboard](https://metal.rackdog.com).
2. Open the organization switcher in the top navigation and select **Create organization**.
3. Enter a name for the organization and confirm.

Once created, you'll be redirected to the new organization and can begin adding members, payment methods, and resources.

## Organization limits

Each account can create up to **3 organizations** by default. If you need more, reach out to support and we'll increase your quota.

## Next steps

* Invite your [teammates](/docs/organizations/teammates).
* Add a [payment method](/docs/billing/payments) so you can provision resources.
* Review how [subscriptions](/docs/billing/subscriptions) are billed.


# Teammates
Source: https://rackdog.com/docs/organizations/teammates

Invite and manage members of your organization

Organizations are shared: anyone you invite can sign in with their own Rackdog account and work with the organization's resources.

## Inviting a teammate

1. Open your organization's settings page in the dashboard.
2. Go to the **Team** section.
3. Select the role you want to assign (**Admin** or **User**).
4. Enter the teammate's email.
5. Send the invite.

The teammate will receive an email invitation. Once they accept and sign in, they'll have access to the organization based on their assigned role.

## Roles

* **Admin.** Can do anything in the organization except remove the owner.
* **User.** Can do most things in the organization, but cannot reset or destroy servers, invite new teammates, or remove existing teammates.

Every organization also has an **Owner**, which is the account that created it. The owner has full access and can't be removed by other admins.

Assign the least-privileged role that still lets the teammate do their job.

## Removing a teammate

From the **Team** section, find the teammate and remove them. They'll lose access to the organization immediately, but their Rackdog account and any other organizations they belong to are unaffected.


# Platform Overview
Source: https://rackdog.com/docs/overview

How Rackdog infrastructure is structured and managed.

Rackdog gives you direct access to physical servers and the networking around them. This page walks through how the pieces fit together so you know what you're working with before you start provisioning.

## Architecture

The platform is organized into four layers:

### Compute

Physical servers in Rackdog data centers, dedicated to a single customer. There's no shared compute and no hypervisor in the way. Each server is provisioned and configured automatically, so you can deploy hardware on demand without losing control over it.

### Networking

Every server gets a public IP, and you can connect servers together over private networking with VLAN-based isolation. The platform supports advanced routing if you need to build a custom topology across your fleet.

### Provisioning

Provisioning is automated end to end: PXE-based workflows handle OS install and initial configuration, and the same process runs consistently across environments. That makes rebuilds and scale-outs repeatable rather than bespoke.

### API

Everything you can do in the dashboard is available through the API: server lifecycle, network configuration, and IP allocation. That makes it straightforward to plug Rackdog into your own tooling, CI/CD pipelines, or infrastructure automation.

## Multi-location deployments

Rackdog infrastructure can span multiple data center locations, and you can distribute servers across them however your architecture requires. Each location operates independently: private networking and VLANs don't extend between locations, so connecting servers across sites is something you'll set up yourself (for example, over a VPN or public routing).

## Security

Isolation is physical by default. Servers are dedicated hardware, networks are separated by VLAN, and the API is authenticated with API keys. Nothing is shared between customers unless you explicitly set it up that way.

## When Rackdog is a good fit

Rackdog is built for teams that want dedicated hardware, full control over networking, predictable performance, and the ability to design their own infrastructure instead of fitting into someone else's model.

## Next steps

* Work through the provisioning and networking guides.
* Provision your first server from the [Quickstart](/docs/quickstart).
* Wire Rackdog into your internal systems through the API.


# Quickstart
Source: https://rackdog.com/docs/quickstart

Provision your first bare metal server in Rackdog.

This guide walks you through provisioning your first server. By the end, you'll have a dedicated bare metal server deployed and reachable.

## Before you start

You'll need a Rackdog account and access to the [dashboard](https://metal.rackdog.com).

## 1. Create an organization

All resources in Rackdog live inside an organization, so that's where you start.

1. Sign in to the dashboard.
2. Create a new [organization](/docs/organizations/overview).
3. Select it to begin working within its scope.

## 2. Add a payment method

You'll need a default credit card on file before you can place an order. From your organization's billing page (`https://metal.rackdog.com/<organization_id>/billing`), click **+ Add New Method** and enter your card details. The first card you add becomes the organization's default. See [Payments](/docs/billing/payments) for more.

## 3. Go to Ordering

From the dashboard, open the **Ordering** page to browse available server plans.

## 4. Pick a plan

Choose a server configuration based on your workload. Plans vary by:

* CPU and memory
* Storage capacity
* Location

## 5. Configure the server

Once you've selected a plan, you'll fill in a few details before checkout:

* **Operating system.** Select the OS to install on the server.
* **Plan.** Confirm or adjust the plan you picked in the previous step.
* **Billing type.** Choose hourly or monthly billing. See [Subscriptions](/docs/billing/subscriptions) for how each is prorated.
* **Hostname.** Give the server a hostname (for example, `web-01.prod`).

## 6. Place the order

Confirm the configuration and submit the order. Provisioning kicks off automatically: the OS is installed, the server is configured, and you'll get access details in the dashboard once it's ready.

## Next steps

* Assign additional IPs or set up a [private VLAN](/docs/overview).
* Add [teammates](/docs/organizations/teammates) to your organization.
* Drive everything through the API to wire Rackdog into your own tooling.