diff --git a/src/routes/docs/+page.svelte b/src/routes/docs/+page.svelte
index 8905666..837f5ff 100644
--- a/src/routes/docs/+page.svelte
+++ b/src/routes/docs/+page.svelte
@@ -10,6 +10,7 @@
| '/docs/colocation/ipmi'
| '/docs/colocation/remote-hands'
| '/docs/colocation/power-budgets'
+ | '/docs/colocation/networking'
| '/docs/vps/ssh'
| '/docs/vps/user-setup'
| '/docs/vps/hardening'
@@ -39,7 +40,7 @@
n: '02',
title: 'Ship your servers',
body: 'Pack up your server (or buy one on eBay) and ship it to our office, our team will then rack and stack it in our Chicago Data Center.',
- code: null
+ cta: { label: 'See the docs →', href: '/docs/colocation/shipping-hardware' }
},
{
n: '03',
@@ -80,7 +81,8 @@
},
{ label: 'Accessing IPMI remotely', soon: false, href: '/docs/colocation/ipmi' },
{ label: 'Requesting remote hands', soon: false, href: '/docs/colocation/remote-hands' },
- { label: 'Power budgets and PDUs', soon: false, href: '/docs/colocation/power-budgets' }
+ { label: 'Power budgets and PDUs', soon: false, href: '/docs/colocation/power-budgets' },
+ { label: 'Colocation Networking', soon: false, href: '/docs/colocation/networking' }
]
},
{
@@ -105,6 +107,7 @@
{ label: 'Ubuntu Server', placeholder: true },
{ label: 'openSUSE Leap', placeholder: true },
{ label: 'Alpine', soon: true },
+ { label: 'Arch', soon: true },
{ label: 'NixOS', soon: true }
]
},
@@ -156,10 +159,7 @@
]; */
-
+
diff --git a/src/routes/docs/account-billing/support/+page.svx b/src/routes/docs/account-billing/support/+page.svx
index 17c13d1..b5bb14b 100644
--- a/src/routes/docs/account-billing/support/+page.svx
+++ b/src/routes/docs/account-billing/support/+page.svx
@@ -2,10 +2,7 @@
import DocsMeta from '$lib/components/DocsMeta.svelte';
-
+
# Contacting Support
diff --git a/src/routes/docs/colocation/+layout.svelte b/src/routes/docs/colocation/+layout.svelte
index 0ef50dc..cf84a7f 100644
--- a/src/routes/docs/colocation/+layout.svelte
+++ b/src/routes/docs/colocation/+layout.svelte
@@ -9,10 +9,11 @@
const { children } = $props();
const nav = [
- { label: 'Shipping hardware to us', href: '/docs/colocation/shipping-hardware' },
- { label: 'Accessing IPMI remotely', href: '/docs/colocation/ipmi' },
- { label: 'Requesting remote hands', href: '/docs/colocation/remote-hands' },
- { label: 'Power budgets and PDUs', href: '/docs/colocation/power-budgets' }
+ { label: 'Shipping Hardware to Us', href: '/docs/colocation/shipping-hardware' },
+ { label: 'Accessing IPMI Remotely', href: '/docs/colocation/ipmi' },
+ { label: 'Requesting Remote Hands', href: '/docs/colocation/remote-hands' },
+ { label: 'Power Budgets and PDUs', href: '/docs/colocation/power-budgets' },
+ { label: 'Colocation Networking', href: '/docs/colocation/networking' }
] as const;
diff --git a/src/routes/docs/colocation/ipmi/+page.svx b/src/routes/docs/colocation/ipmi/+page.svx
index ab32f90..0bd8e01 100644
--- a/src/routes/docs/colocation/ipmi/+page.svx
+++ b/src/routes/docs/colocation/ipmi/+page.svx
@@ -4,22 +4,22 @@
-# Accessing IPMI Remotely.
+# Accessing IPMI Remotely
IPMI, also known as iDRAC on Dell hardware, iLO on HP, and IPMI on Supermicro, gives you out-of-band access to your server. You can power cycle, access a remote console, and manage hardware even when the OS is unresponsive.
---
-## 1. Your IPMI Address.
+## Your IPMI Address
-When we rack your server, we'll assign a dedicated IP address to your IPMI interface and include it in your welcome email. IPMI addresses are on our management network and are **only accessible via our IPMI VPN**, they are not publicly routed.
+When we rack your server, we'll assign an IP address to your IPMI interface and include it in your welcome email. IPMI addresses are on our management network and are **only accessible via our IPMI VPN**; they are not publicly routed.
---
-## 2. Connecting to the IPMI VPN.
+## Connecting to the IPMI VPN
We use WireGuard for IPMI network access. After your server is racked:
@@ -35,27 +35,27 @@ Once connected, your IPMI web interface will be reachable at the IP in your welc
---
-## 3. Logging In.
+## Logging In
-### First login.
+### First Login
We set a temporary password during racking and include it in your welcome email. **Change it immediately after first login.**
-### Dell iDRAC.
+### Dell iDRAC
Navigate to `https://
` in a browser. Log in with username `root` and the temporary password we provide. Go to **iDRAC Settings → User Authentication** to update your credentials.
-### HP iLO.
+### HP iLO
Navigate to `https://`. Default username is `Administrator`. Update via **Administration → User Administration**.
-### Supermicro IPMI.
+### Supermicro IPMI
Navigate to `https://`. Default username is `ADMIN`. Update via **Configuration → Users**.
---
-## 4. Remote Console.
+## Remote Console
All major IPMI implementations provide a remote KVM console (HTML5 or Java). This gives you full keyboard, video, and mouse access as if you were sitting in front of the server.
@@ -67,7 +67,7 @@ Use the remote console to recover from a bad network config, reinstall the OS, o
---
-## 5. Power Management via IPMI CLI.
+## Power Management via IPMI CLI
You can also manage power from the command line using `ipmitool`:
@@ -84,12 +84,12 @@ ipmitool -I lanplus -H -U -P chassis power reset
---
-## 6. Troubleshooting.
+## Troubleshooting
-### IPMI web interface not loading.
+### IPMI Web Interface Not Loading
Confirm your WireGuard tunnel is up with `wg show`. If the tunnel is up but the interface is unreachable, email us as the IPMI port may need to be reconfigured.
-### Forgot IPMI password.
+### Forgot IPMI Password
If you're locked out, [request remote hands](/docs/colocation/remote-hands) and we can reset the IPMI credentials from the physical console.
diff --git a/src/routes/docs/colocation/networking/+page.svx b/src/routes/docs/colocation/networking/+page.svx
new file mode 100644
index 0000000..c962276
--- /dev/null
+++ b/src/routes/docs/colocation/networking/+page.svx
@@ -0,0 +1,237 @@
+
+
+
+
+# Colocation Networking
+
+If you need to configure networking for your colocated server, this is where you can find that information.
+
+---
+
+## Quick TL;DR
+
+We don't expose your public IPv4 or IPv6 address directly to your system. You'll need to statically assign the transit IP addresses for your server, then use your routed public addresses as the preferred source addresses. When your server is racked and ready to use, you'll receive an email with your public IP addresses, IPv6 allocation, and colocation ID allocation. **We do not support DHCP for colocated server IP assignment.** Your static IP configuration for your server should look something like this. In this example, `$ID` is your colocation ID/port, `$PUBLIC_IP` is your routed public IPv4 address, `$PUBLIC_IPV6` is your assigned public IPv6 address, and `$IPV6_DELEGATED_PREFIX` is your delegated IPv6 prefix:
+
+```
+VLAN: 30$ID
+IPv4 transit address: 10.30.$ID.4/24
+IPv4 transit subnet: 10.30.$ID.0/24
+IPv4 transit gateway: 10.30.$ID.254
+Routed public IPv4: $PUBLIC_IP
+IPv6 transit address: 2602:f41f:10:11$ID::4
+IPv6 transit subnet: 2602:f41f:10:11$ID::/64
+IPv6 link-local gw: fe80::$VLAN:ffff
+Public IPv6 address: $PUBLIC_IPV6/128
+Delegated IPv6 prefix: $IPV6_DELEGATED_PREFIX
+```
+
+See [IPMI](/docs/colocation/ipmi) for more information about IPMI access. More information about our networking configuration for IPMI is at the bottom of this page.
+
+See below for a more detailed description of the setup process according to your networking setup.
+
+---
+
+## Firewall Configuration
+
+Fyra Stack colocation does **not** run your traffic through a NAT. That means **you are responsible for configuring your firewall to protect your server**. We recommend using `ufw` or `iptables` to configure your firewall. We also recommend changing your SSH port, as it will be exposed to the public internet and susceptible to brute-force attacks. Refer to your distribution's documentation, or [see our documentation for VPS hardening](/docs/vps/hardening). If you are using a firewall, make sure to allow traffic to your public IP addresses and transit IP addresses.
+
+For compatibility, our router configuration will pass through any traffic from your assigned transit IP (ending in .4) to your public IP. This is primarily in case you use something like Podman or Docker that doesn't follow standard routes. Any inbound traffic MUST still listen on the public IPv4 address; this backup NAT only applies to outbound traffic.
+
+Because we don't support DHCP, **make sure you configure DNS as it will not be configured by default**. We recommend [Cloudflare DNS](https://1.1.1.1), [Quad9](https://quad9.net/), or self-hosting Unbound DNS, depending on how concerned you are about privacy. We peer directly with Cloudflare, so Cloudflare DNS will likely be fastest.
+
+---
+
+## Debian (/etc/network/interfaces)
+Example configuration for Debian systems using `/etc/network/interfaces` for networking configuration. This assumes an interface name of `eno3`.
+
+```sh
+auto lo
+iface lo inet loopback
+ up ip addr add $PUBLIC_IP/32 dev lo || true
+ down ip addr del $PUBLIC_IP/32 dev lo || true
+ up ip -6 addr add $PUBLIC_IPV6/128 dev lo || true
+ down ip -6 addr del $PUBLIC_IPV6/128 dev lo || true
+
+auto eno3
+iface eno3 inet static
+ address 10.30.$ID.4/24
+ gateway 10.30.$ID.254
+ post-up ip route replace default via 10.30.$ID.254 dev eno3 src $PUBLIC_IP
+ post-up sysctl -w net.ipv4.conf.all.rp_filter=0
+ post-up sysctl -w net.ipv4.conf.eno3.rp_filter=0
+ post-up sysctl -w net.ipv4.conf.lo.rp_filter=0
+
+iface eno3 inet6 static
+ address 2602:f41f:10:11$ID::4/64
+ post-up ip -6 route replace default via fe80::$VLAN:ffff dev eno3 src $PUBLIC_IPV6
+ pre-down ip -6 route del default via fe80::$VLAN:ffff dev eno3 || true
+```
+
+---
+
+## systemd-networkd
+Example configuration for systems using `systemd-networkd`. This assumes a network interface name of `eno3`.
+
+Create a file at `/etc/systemd/network/10-eno3.network` (change the interface name accordingly). The following are example contents:
+
+```sh
+[Match]
+Name=eno3
+
+[Network]
+Address=10.30.$ID.4/24
+Address=2602:f41f:10:11$ID::4/64
+IPv6AcceptRA=no
+
+[Route]
+Gateway=10.30.$ID.254
+PreferredSource=$PUBLIC_IP
+
+[Route]
+Gateway=fe80::$VLAN:ffff
+GatewayOnLink=yes
+PreferredSource=$PUBLIC_IPV6
+```
+
+Configure your public IP addresses on interface `lo` by creating `/etc/systemd/network/10-lo.network`:
+
+```sh
+[Match]
+Name=lo
+
+[Network]
+Address=$PUBLIC_IP/32
+Address=$PUBLIC_IPV6/128
+```
+
+---
+
+## Netplan
+For Ubuntu/Debian systems using Netplan with `networkd`, create or edit the file at `/etc/netplan/00-installer-config.yaml`. This example assumes your network interface is named `eno3`.
+
+```yaml
+network:
+ version: 2
+ renderer: networkd
+ ethernets:
+ eno3:
+ addresses:
+ - 10.30.$ID.4/24
+ - 2602:f41f:10:11$ID::4/64
+ accept-ra: false
+ routes:
+ - to: default
+ via: 10.30.$ID.254
+ from: $PUBLIC_IP
+ - to: default
+ via: fe80::$VLAN:ffff
+ from: $PUBLIC_IPV6
+ on-link: true
+```
+
+Not all versions of Netplan support loopback address management, so use `systemd-networkd` if you're not sure what your version supports. Create a file at `/etc/systemd/network/10-lo.network`:
+
+```sh
+[Match]
+Name=lo
+
+[Network]
+Address=$PUBLIC_IP/32
+Address=$PUBLIC_IPV6/128
+```
+
+If you know that your version of Netplan supports loopback management, you can place your public IP addresses directly on your interface in `/etc/netplan/00-installer-config.yaml`:
+
+```yaml
+network:
+ version: 2
+ renderer: networkd
+ ethernets:
+ eno3:
+ addresses:
+ - 10.30.$ID.4/24
+ - $PUBLIC_IP/32
+ - 2602:f41f:10:11$ID::4/64
+ - $PUBLIC_IPV6/128
+ accept-ra: false
+ routes:
+ - to: default
+ via: 10.30.$ID.254
+ from: $PUBLIC_IP
+ - to: default
+ via: fe80::$VLAN:ffff
+ from: $PUBLIC_IPV6
+ on-link: true
+```
+
+---
+
+## NetworkManager
+If your system is using `NetworkManager`, follow these instructions:
+
+First, find your connection name:
+```sh
+nmcli connection show
+```
+
+Next, modify that connection:
+```sh
+nmcli connection modify "" \\
+ ipv4.method manual \\
+ ipv4.ignore-auto-routes yes \\
+ ipv4.addresses 10.30.$ID.4/24 \\
+ +ipv4.addresses $PUBLIC_IP/32 \\
+ +ipv4.routes "0.0.0.0/0 10.30.$ID.254 100 src=$PUBLIC_IP" \\
+ ipv6.method manual \\
+ ipv6.ignore-auto-routes yes \\
+ ipv6.addresses 2602:f41f:10:11$ID::4/64 \\
+ +ipv6.addresses $PUBLIC_IPV6/128 \\
+ +ipv6.routes "::/0 fe80::$VLAN:ffff 100 src=$PUBLIC_IPV6"
+```
+
+If `NetworkManager` rejects the `src=` route attribute, use a dispatcher script instead. Create `/etc/NetworkManager/dispatcher.d/90-colo-public-source` (assuming your interface is named `eno3`):
+```sh
+#!/bin/sh
+
+IFACE="$1"
+ACTION="$2"
+
+[ "$IFACE" = "eno3" ] || exit 0
+[ "$ACTION" = "up" ] || exit 0
+
+ip addr replace 10.30.$ID.4/24 dev eno3
+ip addr add $PUBLIC_IP/32 dev lo 2>/dev/null || true
+ip route replace default via 10.30.$ID.254 dev eno3 src $PUBLIC_IP
+ip -6 addr replace 2602:f41f:10:11$ID::4/64 dev eno3
+ip -6 addr add $PUBLIC_IPV6/128 dev lo 2>/dev/null || true
+ip -6 route replace default via fe80::$VLAN:ffff dev eno3 src $PUBLIC_IPV6
+sysctl -w net.ipv4.conf.all.rp_filter=0 >/dev/null
+sysctl -w net.ipv4.conf.eno3.rp_filter=0 >/dev/null
+sysctl -w net.ipv4.conf.lo.rp_filter=0 >/dev/null
+```
+Make that file executable:
+```sh
+chmod 0755 /etc/NetworkManager/dispatcher.d/90-colo-public-source
+```
+Then reconnect:
+```sh
+nmcli connection down ""
+nmcli connection up ""
+```
+
+---
+
+## A Note on IPMI and DHCP Networking
+
+Your IPMI interface will receive its own IP address over DHCP. Typically, we assign it the IP address of `10.30.$ID.5`, but anything on your server that tries to connect over DHCP will connect to something in the IP range of `10.30.$ID.5`–`10.30.$ID.100`. Anything that is *not* on your transit IP address will not be publicly accessible. For this reason, make sure your server has its networking statically configured.
+
+---
+
+## Post-Networking Setup
+
+We strongly recommend that you harden your system and its configuration after setting up networking. See our [VPS hardening documentation](/docs/vps/hardening) for some recommendations. Specifically, we recommend changing your SSH port, setting up a firewall, and setting up fail2ban for SSH.
diff --git a/src/routes/docs/colocation/power-budgets/+page.svx b/src/routes/docs/colocation/power-budgets/+page.svx
index b962171..bb81eeb 100644
--- a/src/routes/docs/colocation/power-budgets/+page.svx
+++ b/src/routes/docs/colocation/power-budgets/+page.svx
@@ -4,49 +4,49 @@
-# Power Budgets and PDUs.
+# Power Budgets and PDUs
Every colocation slot comes with a power allocation. This guide explains how power is provisioned, what PDUs we use, and how to stay within your budget.
---
-## 1. Power Included Per Plan.
+## Power Included per Plan
Each colocation plan includes a base power allocation measured in amps at 208V:
-### Standard Colocation (1U).
+### Standard Colocation (1U)
Includes **1A at 208V** (~200W) starting out. This covers the typical idle draw of a 1U server with one or two drives and a single PSU.
-### Extended Power Add-on.
+### Extended Power Add-On
If your server draws more than the included allocation, you can purchase additional amps in 1A increments. Contact us before shipping if you expect to exceed the base allocation.
---
-## 2. PDU Details.
+## PDU Details
-### What we use.
+### What We Use
-We use metered Tripp Lite 208V 30A Single phase PDUs. Each PDU circuit is shared across multiple outlets and monitored at the circuit level.
+We use metered Tripp Lite 208V 30A single-phase PDUs. Each PDU circuit is shared across multiple outlets and monitored at the circuit level.
-### Redundant power.
+### Redundant Power
If your server has dual PSUs, we can connect each to a separate PDU on a separate circuit for redundancy. Request this during the intake process and we'll assign outlets accordingly.
---
-## 3. Overages and Enforcement.
+## Overages and Enforcement
-We monitor per-circuit draw continuously. If your server sustains draw above your allocated amount for more than 15 minutes, we'll email you to discuss an upgrade. Persistent overages without a plan upgrade may result in your server being powered down to protect other customers on the same circuit; in accordance with our [Terms of Service](/terms-of-service).
+We monitor per-circuit draw continuously. If your server sustains draw above your allocated amount for more than 15 minutes, we'll email you to discuss an upgrade. Persistent overages without a plan upgrade may result in your server being powered down to protect other customers on the same circuit, in accordance with our [Terms of Service](/terms-of-service).
---
-## 4. Power Cycling Your Server.
+## Power Cycling Your Server
If you need your server power-cycled and IPMI isn't responding, you can request a manual power cycle via [remote hands](/docs/colocation/remote-hands). We'll toggle the PDU outlet and confirm when it's back online.
-For servers with IPMI configured, you can power cycle yourself at any time, see [Accessing IPMI Remotely](/docs/colocation/ipmi).
+For servers with IPMI configured, you can power cycle the server yourself at any time; see [Accessing IPMI Remotely](/docs/colocation/ipmi).
diff --git a/src/routes/docs/colocation/remote-hands/+page.svx b/src/routes/docs/colocation/remote-hands/+page.svx
index ca58869..fb7b6e7 100644
--- a/src/routes/docs/colocation/remote-hands/+page.svx
+++ b/src/routes/docs/colocation/remote-hands/+page.svx
@@ -4,35 +4,35 @@
-# Requesting Remote Hands.
+# Requesting Remote Hands
Remote hands is physical assistance from our team at the data center; plugging in cables, swapping drives, power cycling equipment, or anything else that requires someone to be physically present at your server. We will always ask for your explicit permission before performing hands‑on maintenance.
---
-## 1. What's Included.
+## What's Included
-Remote hands is included with all colocation plans for routine tasks at a rate of $50/hour, with a minimum of one hour per remote hands task. This covers:
+Remote hands is available with all colocation plans for routine tasks at a rate of $50/hour, with a minimum of one hour per remote hands task. This covers:
- Power cycling via PDU or physical power button
- Seating or reseating a drive you've shipped to us
- Connecting or reconnecting a cable
- Visual inspection and status report (LED states, cable condition)
-- Confirming a server is POST-ing via KVM
+- Confirming a server reaches POST via KVM
- OS reinstallation from physical media
- Hardware swap or upgrade (e.g. replacing a failed PSU you've shipped us a replacement for)
- Full server removal, repackaging, and return shipping
---
-## 2. How to Request.
+## How to Request
[Email support@fyrastack.com](mailto:support@fyrastack.com?subject=Remote%20Hands%20Request) with the subject line **Remote Hands Request** and include:
-### What we need to know.
+### What We Need to Know
- Your name and the server hostname or rack unit assignment
- A clear description of what you need done, step by step
@@ -43,19 +43,19 @@ The more specific your instructions, the faster and more accurately we will comp
---
-## 3. Response Times.
+## Response Times
-### Standard requests.
+### Standard Requests
We aim to complete standard remote hands tasks within **4 business hours** of acknowledgement during business hours (9am–5pm CT, Mon–Fri).
-### Urgent requests.
+### Urgent Requests
-For hardware failures or situations affecting production, mark your email as urgent or call our NOC at (630) 381-7677. We'll do our best to respond within **1 hour** and prioritize your request. For time-critical issues outside business hours, include a phone number in your email.
+For hardware failures or situations affecting production, mark your email as urgent or call our NOC at 630-381-7677. We'll do our best to respond within **1 hour** and prioritize your request. For time-critical issues outside business hours, include a phone number in your email.
---
-## 4. What We Won't Do Without Explicit Permission.
+## What We Won't Do without Explicit Permission
In line with our [Privacy Statement](/privacy-statement), we will **never**:
@@ -67,6 +67,6 @@ If a task requires us to interact with your OS or data, we will confirm the spec
---
-## 5. After the Task.
+## After the Task
We'll reply to your request email with a summary of what was done, the outcome, and any observations (e.g. a drive that looked physically damaged, a cable that was loose). If something didn't go as expected, we'll tell you immediately rather than leaving you to figure it out.
diff --git a/src/routes/docs/colocation/shipping-hardware/+page.svx b/src/routes/docs/colocation/shipping-hardware/+page.svx
index 3aaab91..c7b4e0c 100644
--- a/src/routes/docs/colocation/shipping-hardware/+page.svx
+++ b/src/routes/docs/colocation/shipping-hardware/+page.svx
@@ -4,22 +4,22 @@
-# Shipping Hardware to Us.
+# Shipping Hardware to Us
Before your server can go live in our Chicago DC, we need to receive it at our office location. This document covers how to pack, label, and ship your hardware so it arrives safely and gets racked without delays.
---
-## 1. Before You Ship.
+## Before You Ship
[Fill out this form](/services/colocation) before sending anything. We'll confirm your colocation slot is ready, assign you a rack unit, and give you a receive authorization number (RAN) to include with your shipment. **Shipments arriving without a RAN may be refused or delayed.**
---
-## 2. Shipping Address.
+## Shipping Address
Send hardware to:
@@ -31,44 +31,44 @@ Include your **RAN** and your **name or company name** on the outside of every b
---
-## 3. Packing Your Server.
+## Packing Your Server
-### Use the original packaging if you have it.
+### Use the Original Packaging If You Have It
Original server packaging is designed exactly for this. If you still have the box and foam inserts, use them.
-### If you don't have original packaging.
+### If You Don't Have Original Packaging
- Use a double-walled corrugated box sized to fit snugly around the server.
- Wrap the server in at least 2 inches of foam or bubble wrap on all sides.
- Fill any empty space with packing peanuts or air pillows — servers should not shift inside the box.
-- Do not ship with loose components (RAM sticks, drives), instead please bag and tape them separately inside the box.
+- Do not ship with loose components, such as RAM sticks or drives. Instead, please bag and tape them separately inside the box.
-### Rails and accessories.
+### Rails and Accessories
-You must ship OEM rack rails (please don't send us generic rails) and other accessories with your server. Please pack them in a separate box and label it with the same RAN and mark it as a companion shipment.
+You must ship OEM rack rails (please don't send us generic rails) and other accessories with your server. Please pack them in a separate box, label it with the same RAN, and mark it as a companion shipment.
---
-## 4. What to Include.
+## What to Include
Ship the following with your hardware:
-### A printed packing slip.
+### A Printed Packing Slip
Include a sheet inside the box with your name, contact email, RAN, and a brief description of the hardware (make, model, number of drives, number of PSUs).
-### Power cables.
+### Power Cables
Include at least two IEC NEMA C13 to C14 power distribution cables that are at least 6ft long. If we need to acquire power cables for your server, we can do that, but at an additional charge.
-### Any KVM or console adapters.
+### Any KVM or Console Adapters
If your server requires a special adapter for the serial console or VGA, include it. We use standard VGA and USB, but some servers need dongles.
---
-## 5. Carriers and Insurance.
+## Carriers and Insurance
We recommend shipping with **FedEx** or **UPS** with full declared value insurance and signature required on delivery. For high-value hardware (over $2,000), we strongly recommend freight or white-glove shipping.
@@ -76,7 +76,7 @@ Keep your tracking number. We'll confirm receipt via email once your shipment is
---
-## 6. After We Receive It.
+## After We Receive It
Once your server arrives: