anisette-v3-server: a small D service for SideStore and AltStore

The server exists to answer one narrow protocol request

anisette-v3-server is described in its README as a supposedly lighter alternative to omnisette-server, and that word supposedly is doing useful work in the sentence. The scope is narrow. The service exists so that SideStore and AltStore clients can complete the step where they need an anisette response before they can install an application. The README states that, like omnisette-server, it supports both currently supported SideStore protocols, anisette-v1 and anisette-v3, and that it can also be used with AltServer-Linux. That is the whole functional contract as documented. There is no configuration file to speak of, no pipeline, no storage engine and no administration interface. The repository layout reflects that, with a source directory, a dub.json and dub.selections.json for the D package manager, a Dockerfile, a GitHub Actions directory and one Ansible playbook file at the top level. If you are evaluating it, you are evaluating a sidecar that does one protocol well and gets out of the way.

Docker is the shortest route and the port is the whole interface

The container run is one command, and it publishes the service on port 6969 with a named volume for its data directory.

docker run -d --restart always --name anisette-v3 -p 6969:6969 --volume anisette-v3_data:/home/Alcoholic/.config/anisette-v3/lib/ dadoum/anisette-v3-server

Three details in that line are worth reading carefully. The port mapping publishes 6969 on the host, which is the only thing the server exposes. The volume mounts to the lib directory inside the anisette-v3 configuration path, so the client state the service builds up survives container replacement rather than being lost every time you restart. And the image name has no tag, so you get whatever the registry currently holds for latest, which is a point to keep in mind when a change in behaviour matters to you. The Dockerfile explains the rest. It builds in a Debian builder stage with the D compiler, dub and clang, compiles a static binary with the ldc2 compiler and a release build mode, and copies the artefact into a slim Debian runtime that carries only curl and the libplist libraries. The runtime stage also creates the provisioning folder and a rootless user named Alcoholic that owns both the home directory and the opt directory, and the container runs as that user rather than as root.

Compiling from source means installing a D toolchain by hand

The source build uses dub, the D package manager, and needs a specific set of system packages.

apt update && apt install --no-install-recommends -y ca-certificates ldc git clang dub libz-dev libssl-dev
git clone https://github.com/Dadoum/anisette-v3-server.git; cd anisette-v3-server
DC=ldc2 dub build -c "static" --build-mode allAtOnce -b release --compiler=ldc2
stat anisette-v3-server

The package list tells you what the build actually depends on, which is a useful thing to know before you start: certificates, the LDC D compiler, git, clang, dub itself, and the zlib and OpenSSL development headers. The build flags matter too. The configuration is static, so the resulting binary does not need the D runtime shared libraries present on the target machine, the build mode is allAtOnce, and the compiler is set to ldc2 explicitly with DC also pointing at ldc2. The final stat call is there so you can see what you produced. The dub.json and dub.selections.json files in the repository pin the dependency selections, so a build uses the versions the author tested rather than whatever the resolver picks, which matters for a static build where a library bump can change what links.

The published images skip ARMv7 for a good reason

The README is unusually forthcoming about a coverage gap. The GitHub Actions workflow publishes the dadoum/anisette-v3-server image for linux/386, linux/amd64 and linux/arm64/v8 only, and linux/arm/v7 is not built by Actions because LDC builds under QEMU are unreliable for that target. In other words, the missing architecture is not an oversight but a workaround for a real toolchain problem, with the build done under emulation producing unreliable results. The documented alternative is to build the image locally on a native ARMv7 system, or another environment able to produce a compatible binary.

docker buildx build --platform linux/arm/v7 -t dadoum/anisette-v3-server:armv7 .

That is a small thing to know, but it is the kind of detail that turns into a wasted evening if you assume the published images cover every 32-bit ARM target. It also tells you something about the project's scope of support, which is centred on the architectures where the client tools are commonly run. The base images are pinned to a dated Debian stable tag for the builder and to a plain Debian stable tag for the runtime, and the runtime image keeps the libplist libraries present because the server links against them.

Ansible is included for people who provision many hosts

For a service that runs next to a sideloading client on several machines, the repository ships a playbook rather than only container commands. The README says that if you want to quickly set up anisette-v3 with Ansible, you can use the setup-anisette-v3-ansible.yaml playbook at the top of the repository. The instructions are minimal, because the playbook does the work: set up your inventory and choose the desired host in the playbook, tweak your parameters or ansible.cfg for the remote user you use, and note that it requires root.

ansible-playbook -i inventory setup-anisette-v3-ansible.yaml -k

The -k flag asks for a connection password interactively, which fits the playbook's host-based setup, though root is still required. The value of this route is that it installs and configures the service as a managed process on a host rather than as a container, which fits a fleet of machines where you already run Ansible and do not want to add a container runtime. The trade-off is that the playbook is a single file with no configuration in the repository beyond it, so if you need more than the default installation, you are editing a script rather than consuming a parameterised module.

What this service is not, and where the alternative sits

Being clear about boundaries helps here more than usual. This is not a general purpose anisette implementation for arbitrary clients, and the README does not describe an API beyond the two protocols it supports, so treat any other client as unverified. It is also not a sideloading tool itself: it does not sign applications, it does not manage Apple identifiers and it does not talk to the app store, it only answers the anisette requests a client makes along the way. The alternative is the server it names, omnisette-server, which is the reference implementation the README compares against, and the stated difference is weight, with this project aiming to be the lighter option. That is a claim about footprint rather than about compatibility, and the protocol support lines are parallel, since both cover anisette-v1 and anisette-v3. The other alternative is running the client against a public anisette service, which removes the deployment work but hands the request path to someone else's host. What you give up by self-hosting is that convenience, and what you gain is that the request path stays on your own machine and the client state lives in a volume you control.

Maintenance state, licensing and the missing release stream

The repository is not archived and the last push was on 2026-09-23, so the code is being worked on rather than frozen. Beyond that there is very little to go on, and a reader should be honest about it. The repository has no GitHub releases, so there is no published version stream, no upgrade notes and no binary release page to point at. The licence is listed as unknown in the repository metadata rather than as a recognised identifier, and there is no LICENSE file among the top level entries, which are the GitHub directory, the gitignore, the Dockerfile, the README, dub.json, dub.selections.json, the Ansible playbook and the source directory. If you plan to run this inside an organisation with a policy on third-party licences, that is a question to raise with the author rather than something the repository answers, and the difference matters more for a service like this than it would for a library, since a self-hosted service you operate is squarely in the path of your own compliance work. The practical adoption advice follows from the same facts: pin the image by digest, keep the source checkout so you can rebuild, and treat the current state of the repository as the version you are running.

Editorial conclusion

Adopt anisette-v3-server when you run a SideStore or AltStore workflow and want a small self-hosted service for the anisette requests those clients make, especially when you prefer a static Linux binary or a container over the other server. Skip it if you need features beyond the anisette protocols or a maintained release stream with published binaries, since the repository has no tagged releases. Verify first that your target architecture is covered, that the client can reach port 6969, and that the provisioning folder and the mounted data volume are writable by the unprivileged account the image runs as.

Frequently asked questions

Official sources

1. Dadoum/anisette-v3-server on GitHub
2. Issues
3. README