SynoCommunity/spksrc: building native Synology packages from source

The gap spksrc fills between upstream source and Package Center

Synology's Package Center ships a curated set of packages. Anything outside that set has to arrive as an SPK file that the NAS recognises, built for the right CPU architecture and the right DSM generation. spksrc is the build system SynoCommunity uses to produce those files. The README describes it plainly: a cross compilation framework intended to compile and package software for Synology NAS devices, with the resulting packages distributed through the SynoCommunity repository.

The audience is narrow and specific. You are writing or maintaining a package recipe, or you are rebuilding an existing one. You are not the person clicking Install in Package Center. The framework assumes you can read a Makefile, that you understand why a build host needs an i386 architecture enabled, and that you are willing to run a Debian-based environment rather than build directly on the NAS. If any of those assumptions is wrong, spksrc is the wrong layer of the stack to be working at.

How the framework is organised: toolchains, cross packages, spk recipes

The top-level layout separates concerns in a way that is worth understanding before you touch anything. The toolchain/ directory holds per-DSM toolchains, named syno-*, and the root Makefile derives its list of available architectures from them with a wildcard over toolchain/syno-* and a substitution that strips the syno- prefix. That means the set of architectures you can target is not hardcoded in the build logic; it is whatever toolchain directories exist.

Alongside that, cross/ holds the cross-compiled dependency packages, spk/ holds the individual package recipes (the Makefile computes SUPPORTED_SPKS by globbing spk/*/Makefile), and native/ holds packages built for the build host itself. The mk/ directory carries the included rule files, and the root Makefile explicitly includes mk/spksrc.common.mk, mk/spksrc.rules/tests.mk and mk/spksrc.rules/dependency-tree.mk. The comment in the Makefile notes that the base definitions are included explicitly rather than relied upon through tests.mk, so that root targets and make help do not depend on the still-evolving tests.mk. That is a small but telling detail: the project is aware that its own test infrastructure is in motion and has insulated the entry points from it.

The help system is generated by an awk script embedded in the Makefile. Only targets carrying a ## description are listed, which is why internal hook targets such as pre_*, post_* and *_msg never appear in make help. Beyond the documented targets there are two pattern families: a bare package name builds one SPK, and a fully qualified form such as spk-<spk>-<arch>-<tcversion> builds one SPK for one architecture, with the Makefile giving make spk-tvheadend-x64-7.1 as the shape of that invocation. If you want to build for a single architecture instead of all of them, that pattern is the mechanism.

Installing spksrc with Docker and building your first SPK

The README presents three development environments: Docker, a Debian 13 virtual machine, and LXC. Docker is the shortest path, and the README states it supports Linux and macOS but not Windows, because of limitations of the underlying file system. The first step is to fork and clone the repository, then pull the published container image.

git clone https://github.com/YOUR-USERNAME/spksrc
docker pull ghcr.io/synocommunity/spksrc

Next, start the container with the cloned repository mounted at /spksrc. The command differs between Linux and macOS: on macOS the README adds an environment variable that changes the tar command used during packaging.

cd spksrc
docker run -it --platform=linux/amd64 -v $(pwd):/spksrc -w /spksrc ghcr.io/synocommunity/spksrc /bin/bash

On macOS the documented invocation adds -e TAR_CMD="fakeroot tar" to that same docker run line. Once inside, the README points to the Developer Guide at docs.synocommunity.com for the actual build instructions, so the container gets you a working toolchain rather than a finished package. From the repository root, make help prints the grouped list of documented targets; passing a topic filters it, as in make help-clean. To build a single package for a single architecture, use the qualified pattern the Makefile documents.

make help
make help-clean
make spk-tvheadend-x64-7.1

If you prefer not to use Docker, the README recommends a 64-bit Debian 13 virtual machine and states that non-x86 architectures are not supported. The VM path requires enabling the i386 architecture, updating apt, and installing a long package list that the README says is kept in sync with the Dockerfile. The LXC path follows the same package list, adds a spksrc user with uid 1001, and copies the skeleton profile and bashrc into that user's home directory. Both paths end at the same Developer Guide.

Where spksrc gets in your way

The Windows exclusion is not a footnote. It is stated twice in the README, once for Docker and once for the virtual machine and LXC environments, and the Docker case is attributed to file system limitations. If your team develops on Windows, the framework will not meet you halfway, and you will need a Linux or macOS host regardless of which of the three environments you choose. The same restriction applies to CPU architecture: non-x86 hosts are not supported, so an ARM workstation is out.

The second constraint is the coupling between toolchain availability and DSM version. The repository's release list shows toolchains/dsm7.0 as a separate tagged artefact, alongside kernel tags for SRM 1.3 and SRM 1.2. Building for a DSM generation therefore depends on that generation's toolchain being present in the tree. The README also links a meta issue for tracking the status of former packages under DSM 7, which is an admission that the migration was not uniform across the package catalogue.

The third is the upgrade hazard, and it is the one that affects end users rather than builders. The README states in capitals that package configuration settings may be lost following an upgrade to DSM 7 and the execution of a Package repair, and advises backing up settings and configuration for SynoCommunity packages before installing DSM 7. A build framework cannot protect you from that; it is a property of how packages are repaired on the NAS. Separately, the README notes that manually installing a DSM 6 package on DSM 7 still produces errors such as invalid file format or package requires root privileges, even though the repository itself stopped serving DSM 6 packages to DSM 7 systems after a fix that the README says has been online since February 2024.

spksrc against building inside a Synology Docker container or with Synology's own toolchains

The obvious alternative for someone who wants third-party software on a NAS is to skip native packaging entirely and run the application in a Docker container on a Synology model that supports Container Manager. That approach sidesteps spksrc completely: you pull an upstream image, mount your data, and never produce an SPK. The difference in approach is architectural rather than cosmetic. A container keeps the application's own dependency tree intact and lets you upgrade by pulling a new image. An SPK built with spksrc produces something Package Center can install, start and stop alongside the NAS's own services, with the package's dependencies cross-compiled into the tree under cross/ rather than resolved at runtime. That integration is exactly what you lose with a container, and it is the reason packages such as media servers and backup clients exist as SPKs at all.

The other alternative is to use Synology's own toolchains directly and write your own build scripts. spksrc is a layer on top of those toolchains, adding the recipe format, the dependency resolution, the multi-architecture build patterns and the packaging step. If you only ever build one package for one architecture, that layer may cost more than it returns. If you maintain several packages across several architectures and DSM generations, the pattern targets and the shared cross/ dependency tree are the payoff.

Maintenance cost, licensing and what to check before you commit

The repository is not archived and the last push was on 2026-09-23, so it is current. The release cadence is uneven: DSM 7.0 toolchains were tagged on 2026-07-16, while the SRM 1.3 and SRM 1.2 kernel tags both date to 2025-09-17. That suggests toolchain and kernel artefacts are published when they change, not on a schedule. Upgrading spksrc itself means pulling a new container image and rebuilding; the README's package lists are explicitly kept in sync with the Dockerfile, so a VM or LXC environment built from the README's list can drift from the container if you do not re-check it.

The licence field is reported as NOASSERTION, which means the repository's licence could not be identified automatically. The repository does contain a LICENSE.md file at the top level, so the terms are stated somewhere in the tree, but the metadata does not tell you what they are. Read LICENSE.md directly before you redistribute anything built with the framework, and note that the licence of spksrc itself is separate from the licences of the upstream projects you compile with it. Nothing here is legal advice; the practical point is that you cannot infer the terms from the repository metadata.

Before adopting it, check three concrete things: whether toolchain/ contains a syno-* directory for your target DSM version, whether the package you care about already has a recipe under spk/, and whether your build host is x86 Linux or macOS. If the recipe exists and the toolchain exists, the remaining work is configuration, not framework development.

Editorial conclusion

Adopt spksrc if you maintain a package that Synology's own Package Center does not carry, or if you need to rebuild a SynoCommunity package for a specific architecture and DSM version. Do not adopt it if you only want to install software on a NAS: the packages themselves are distributed through the SynoCommunity repository, and the README warns that package configuration settings may be lost during a DSM 7 upgrade and Package repair, so back up settings first. Before committing, verify two things: that your target DSM version has a toolchain under toolchain/ (DSM 7.0 toolchains were released as a separate tag in July 2026), and that your build host is x86 Linux or macOS, because the Docker environment explicitly does not support Windows.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. SynoCommunity/spksrc on GitHub