How HTTPBOOT Revolutionizes Server Provisioning at ByteDance

HTTPBOOT Overview

HTTPBOOT is a new network installation solution jointly developed by ByteDance’s STE and ICS teams to address a series of problems encountered in daily server provisioning, saving a large amount of operational manpower.

Current boot problems and requirements

Strong dependence on MAC address : Using MAC/DUID for server identification is unreliable and labor‑intensive, especially when MAC addresses are changed or network cards are replaced.

Unstable TFTP/UDP transmission : PXE relies on UDP/TFTP, which often fails in noisy data‑center networks, delaying machine delivery.

Vendor‑dependent firmware fixes : Issues in UEFI firmware require waiting for vendor releases, slowing down problem resolution.

Additional needs from the ICS team include free rack‑mounting without pre‑reserved slots and a customizable boot API compatible with various server models.

Why choose HTTPBOOT

HTTPBOOT offers high stability, compatibility, reliability, and flexibility by using Linux‑based HTTP/TCP instead of TFTP/UDP, providing syslog‑based logging, leveraging powerful Linux network drivers, and supporting both HTTP boot and fallback PXE boot. Its open‑source ecosystem enables easy customization and cross‑platform deployment.

HTTPBOOT Practice

HTTPBOOT Journey in ByteDance

2021: Integrated as a feature of CloudFirmware and launched with the firmware.

2022: Used in a few data‑centers as a fallback tool for UEFI boot failures.

2023: Adopted as the primary provisioning solution in internal data‑centers, saving substantial manpower.

2024: Extended to non‑server board projects.

HTTPBOOT Working Principle

The provisioning flow after introducing HTTPBOOT replaces the traditional UEFI+PXE process with an HTTP‑based workflow. For Linux‑based machines, the unstable UDP boot issue is fully resolved; for UEFI machines, a small 5.8 MB HTTPBOOT tool is downloaded instead of a 40 MB PXE image, reducing failure probability.

Key steps include:

DHCP server detects the client’s Option 61 and returns the custom API URL.

HTTPBOOT sends the machine’s serial number (SN) to the backend, which dynamically binds an IP address, eliminating MAC‑address dependence and enabling free rack‑mounting.

Based on the SN, the backend returns either a boot command for normal provisioning or a fallback command for non‑provisioning devices.

Example of a fallback command returned by the backend:

<code>#!ipxe
sanboot --no-describe --drive 0x80</code>

Example of a normal provisioning command returned by the backend:

<code>#!ipxe
http://[X:XXX:X:XXX:...]:88/httpboot.cfg/?IP=fdbddc01002b0f1c0000000000000028</code>

These commands demonstrate HTTPBOOT’s ability to handle diverse scenarios through a flexible API.

Results and Future Plans

HTTPBOOT has been closed‑loop tested in the R&D stage and deployed at ByteDance’s internal data‑centers, completing over 100,000 provisioning operations. It has delivered measurable benefits in stability, reliability, flexibility, and compatibility. Future work includes broader internal promotion and continued collaboration with open‑source communities such as OCP, OSFF, LinuxBoot, and U‑ROOT.