AuxXxilium/arc Loader: A Guided Redpill Bootloader for DSM 7.x on Non-Synology Hardware

What Arc actually is, and who it is for

Arc is a customized Redpill Loader for DSM 7.x. It is not a NAS operating system. The README is explicit on this point: Arc and DSM are independent from each other, and Arc is a boothelper for DSM. Everything the user interacts with after installation is Synology's software, running on hardware Synology did not certify.

The audience is the Xpenology community: people with spare x86 machines, home-lab servers, or hypervisors who want DiskStation Manager without buying a DiskStation. The README frames the project as educational and learning purpose only, and states that commercial use is not permitted and strictly forbidden. That single line rules out a large class of deployments before any technical question is asked.

Arc's differentiator against the raw Redpill tooling is packaging. The repository describes enhanced hardware support, addons, and guided (semi-automated) installation, with multiple customization options built in. A user who has compiled a loader by hand before will recognize the value: the model selection, driver injection and image generation steps are folded into one flow rather than assembled from separate scripts.

How the loader builds and boots: the mechanism

The repository is Shell at its core, with a Dockerfile and a Taskfile.yaml at the top level, plus files/, scripts/ and img-gen.sh. The name img-gen.sh is the clearest signal of the data flow: the project generates a boot image, arc.img, rather than shipping a fixed binary that every user must patch themselves.

The loader is modified to run on different hardware, and the README points to the wiki for details. The guided installation means the user picks a DSM model and the loader assembles the matching boot configuration, including the addons that model needs. This is the part that separates Arc from a plain Redpill checkout: the model-to-driver mapping is prebuilt and tested, and the README warns that any user-specific custom modification of the tested and prebuilt bootloader images could potentially cause irreversible data destruction.

That warning is not boilerplate. A bootloader sits underneath the storage stack. If the loader presents the wrong disk controller configuration to DSM, the operating system can initialize volumes it should have left alone. The project's position is that the tested images are the safe path and hand edits are the user's risk.

Installing Arc and reaching the DSM installer

The README does not give a step-by-step install in the repository text; it directs readers to the wiki at xpenology.tech/wiki with the note Read me first. The repository does contain a Dockerfile that wraps a built arc.img in qemux/qemu so that docker run boots it directly, and the comment states this avoids writing a Compose file or volume mount. docker.md is named as the manual bind-mount alternative.

The Dockerfile copies arc.img into the image and sets defaults for RAM, CPU, disk format, disk type and disk size:

FROM qemux/qemu:latest
COPY arc.img /arc.img
ENV RAM_SIZE="4G"
ENV CPU_CORES="2"
ENV DISK_FMT="qcow2"
ENV DISK_TYPE="sata"
ENV DISK_SIZE="32G"

Those environment variables are the knobs a first-time user will touch. RAM_SIZE and CPU_CORES describe the virtual machine Arc will boot into, not the host. DISK_SIZE defaults to 32G, which is the guest disk, not the storage pool DSM will later manage.

The image exposes the ports you need to reach the running system:

EXPOSE 5000 5001 7080 7304 7681

Ports 5000 and 5001 are DSM management (HTTP and HTTPS). Ports 7080, 7304 and 7681 are Arc's own web config, file browser and terminal, matching HTTPPORT, DUFSPORT and TTYDPORT defaults. The Dockerfile comment notes these can be remapped if you changed them through the loader's Change Loader Ports menu. After the container starts, the expected sequence is to open the Arc web configuration on 7080, complete the guided model selection, and then continue to the DSM installer on 5000 or 5001.

The ARGUMENTS variable carries the QEMU device line that attaches arc.img as a removable USB disk with a high boot index, which is how the guest firmware finds the loader before any data disk:

ENV ARGUMENTS="-device nec-usb-xhci,id=usb0,multifunction=on -drive file=/arc.img,media=disk,format=raw,if=none,id=udisk1 -device usb-storage,bus=usb0.0,port=1,drive=udisk1,bootindex=999,removable=on"

If you are installing to bare metal rather than a hypervisor, the Dockerfile is irrelevant and the wiki is the only documented path. The repository does not reproduce those steps in text.

Where Arc is the wrong choice

The licence and the README's own scope statement are the first limitation, and they are not negotiable through configuration. Commercial use is not permitted and strictly forbidden. If you are building a storage appliance for a business, or reselling a preconfigured box, Arc is the wrong tool regardless of how well it boots.

Second, Synology does not support this. DSM and all parts of it are under Copyright and ownership by Synology Inc. There is no vendor path for a bug that only appears on Arc hardware. QuickConnect and other account-bound features depend on Synology's services rather than the loader, which the repository does not document either way, so treat them as unverified until the wiki says otherwise.

Third, the failure mode is data loss, not a failed boot. A misconfigured loader that boots successfully but presents storage differently than the previous loader did can trigger DSM to treat existing volumes as new. The README warns that custom modification of the tested images could potentially cause irreversible data destruction. The practical consequence: never experiment with loader changes on a system holding the only copy of anything.

Fourth, the project carries an explicit liability disclaimer. The author states he is not responsibly liable for damage or personal loss of any types. That is normal for this category, and it means the support you get is community support.

Arc against arc-essential and the plain Redpill route

The README lists two direct alternatives from the same author. Arc Loader Essential is Arc Loader with reduced size, and it is only for Linux 5.x models. That is a real architectural difference, not a repackage: if your target DSM model uses a newer kernel series, Essential is not an option, and if you are space-constrained on the boot medium and your model fits Linux 5.x, Essential removes components you will never load. Arc Beta is the beta release of Arc, for users who want changes before they reach the main repository. Choosing between the three is a question of model support and appetite for untested builds, not of features.

Against the original redpill-load work by TTG and the contributors the README credits, Arc's difference is the guided flow and the prebuilt image generation. A raw Redpill setup asks the user to assemble the loader themselves; Arc's img-gen.sh and model selection do that assembly. The trade-off is that you inherit Arc's choices about which drivers and addons are included, and the repository does not document a supported path for removing them beyond the warning against custom modification.

There is also Arc Control, a DSM app for Arc Loader, and Arc Utilities, described as useful tools to install DSM apps on Xpenology. Those sit on top of a working installation rather than replacing the loader.

Maintenance, releases and the GPL-3.0 question

The repository is not archived, and the last push was on 2026-09-20. Releases are frequent and closely spaced: 4.0.4 on 2026-09-13, 4.0.3 on 2026-09-12, and 4.0.2 on 2026-09-12. Three patch releases in two days suggests a fast fix cadence around a 4.0 line, and it also suggests that pinning to a specific release and reading the diff before upgrading is worth the effort on a system that holds data.

Upgrade cost is not only the loader. Arc is bound to DSM 7.x, so a DSM point upgrade and a loader upgrade interact. The README does not document rollback, and it does not document a compatibility matrix between Arc versions and DSM versions in the repository text; that information is pointed at the wiki. Plan for the wiki, not the repository, to be the source of truth on version pairing.

The licence is GPL-3.0, which governs Arc's own code. It does not govern DSM, which the README states is under Copyright and ownership by Synology Inc. A GPL grant on the bootloader does not grant anything with respect to Synology's software, and it does not override the README's prohibition on commercial use. Read those as two separate constraints. This is not legal advice; if commercial deployment is on the table, the README's own wording already answers it.

Editorial conclusion

Adopt Arc if you have spare x86 hardware, want DSM 7.x, and accept that Synology does not support this configuration. Do not adopt it for commercial deployment: the README states commercial use is not permitted and strictly forbidden. Before flashing, verify the target model appears in Arc's guided model list, confirm your NIC is covered by the enhanced hardware support, and check the wiki for the bootloader's current behaviour on your hypervisor.

Frequently asked questions

Official sources

1. AuxXxilium/arc on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases