# Service Fabric: what microsoft/service-fabric actually gives you, and how to build it

> The microsoft/service-fabric repository is the Linux build tree for Microsoft's distributed systems platform, not a download you install. It targets engineers who need to compile the runtime from source and who accept a build measured in hours and roughly 70GB of disk.

**microsoft/service-fabric** — Service Fabric is a distributed systems platform for packaging, deploying, and managing stateless and stateful distributed applications and containers at large scale.

- Repository: https://github.com/microsoft/service-fabric
- Website: https://docs.microsoft.com/en-us/azure/service-fabric/
- Stars: 3,065 · Forks: 401
- Language: C++
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-service-fabric

## What problem the microsoft/service-fabric repository solves

Service Fabric is a distributed systems platform for packaging, deploying and managing stateless and stateful distributed applications and containers at large scale. That is the whole product. The repository you are looking at is narrower: it is the Linux version of the source tree, the place where the platform is built from source rather than installed as a package. The README says plainly that you need a Linux machine to build this project.

So the audience is not every team that wants to run microservices. It is the subset that needs to compile the runtime, produce installer packages, or inspect how the platform is assembled. The README even ships a subsystem explorer that maps the core architecture to the folder structure, which tells you the repository is meant to be read as well as built. If you want a cluster today, this is the wrong entry point.

## How the build actually works: Docker, ninja and runbuild.sh

The mechanism is a shell script that drives a Docker container. The README's build requirements are based on clean builds using ninja with the command runbuild.sh -c -n. The build environment depends on Docker, and runbuild.sh starts the build inside a container, with output placed into the out directory. Passing -createinstaller produces installer packages as well.

The container is not built from nothing. The README states that the build container is based off a base image that includes Service Fabric dependencies that have either not yet been open sourced or must be included because of technical constraints, and it gives one example: some .NET files currently only build on Windows but are required for a Linux build. That is the most honest sentence in the repository. A build that depends on a prebuilt base image containing non-open-source pieces is reproducible in practice only as long as that image is published. If you were hoping to audit the full toolchain from source, this design stops you at the image boundary.

Below the script is a data flow of sorts: clone the repository, run the script from the root, and the container pulls packages, adds Service Fabric internal dependencies and applies patches. The costs are documented as a table rather than a sentence. On a Standard_D8s_v3 with 8 cores and 32GB of memory the estimate is about 4 hours; on 16 cores and 64GB, about 2 hours; on 32 cores and 128GB, about 1 hour. The README also warns that on a Standard_D4s_V3 with 4 cores and 16GB the build may fail, and that limiting parallelism with the -j switch may let a smaller machine finish. Roughly 70GB of disk is required.

## Installing Docker and running your first build

There is no package to install here. The README tells you to get a Linux machine, install Docker, clone the repository and run the build script. The Docker instructions it gives are for Ubuntu, reproduced here as the README shows them:

```bash
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
sudo apt-get update
sudo apt-get install -y docker-ce
```

Docker requires root by default. The README offers an optional step to run it as a regular user by adding yourself to the docker group, and notes that if you skip it you must run all docker commands with sudo:

```bash
sudo usermod -aG docker ${USER}
su - ${USER}
```

With Docker in place, clone the repository and run the build from the root directory. The README gives this as the full build:

```bash
./runbuild.sh
```

What you should see is a container starting, packages being pulled, and a build that ends with artifacts in the out directory. For installer packages, the README adds the -createinstaller option:

```bash
./runbuild.sh -createinstaller
```

If you would rather build the container locally instead of pulling the base image, the README provides a script for that, run as root:

```bash
sudo ./tools/builddocker.sh
```

One failure mode is documented directly. Behind a firewall, if the firewall blocks the DNS Docker uses, packages fail to download during the docker build step. The fix is to point Docker at your own resolvers in /etc/docker/daemon.json and restart the daemon:

```json
{
    "dns": ["<my DNS server IP here>", "<my DNS secondary server IP here>"]
}
```

```bash
service docker restart
```

After a successful build the README points to two separate documents rather than inlining the steps: docs/cluster_deployer_test.md for testing a local cluster and docs/install_packages_and_deploy_cluster.md for deploying a local cluster from the build. Both files are referenced, not summarized, so treat them as the next thing to read.

## Where the repository falls short

The release schedule table is the clearest limitation. It lists versions 8.0 through 10.1 with release dates from March 2021 to November 2023, and the README calls those dates advanced estimates subject to change. There is no entry for anything after 10.1, so anyone trying to map a current runtime version onto this table is reading a schedule that stops in 2023.

The repo status section is equally candid. It says the team is in the process of moving development to GitHub, that until then feature development continues internally, and that updates will be posted here and on the team blog. A repository whose own status note describes an unfinished migration is telling you that the public tree is not the primary development surface. The checklist under that note shows build tools for Linux, basic tests for Linux builds, and a container image with build tools as complete items. It does not claim parity with the internal tree.

The build itself is the other constraint. Hours of wall clock time and roughly 70GB of disk are not incidental. On a 4-core, 16GB machine the documented outcome is possible failure, not a slow success. And because the container depends on a base image with dependencies that have not been open sourced, you cannot fully rebuild the toolchain from the repository alone. If your requirement is a fully auditable build chain, this is the wrong tool.

## Service Fabric versus Kubernetes and AKS

The comparison people search for is Service Fabric versus Kubernetes, and the architectural difference is the reason the project exists. Service Fabric is built around stateful services as a first-class concept: the description covers packaging, deploying and managing stateless and stateful distributed applications and containers. Kubernetes, and therefore AKS, treats stateful workloads through controllers layered on top of a scheduler designed around stateless pods and external storage.

That difference decides the choice. If your services keep state in-process, coordinate through named partitions and replicas, and you want the platform to handle placement and failover of that state, Service Fabric models it directly. If your workloads are stateless HTTP services and your state lives in a database or object store, Kubernetes gives you a larger ecosystem and no reason to take on the build cost documented here. Note also that the repository covers Windows and Linux, any cloud, any datacenter, across geographic regions, or your laptop, so the platform is not tied to one host. The trade-off is operational: the source build is heavy, the release schedule in the README ends at 10.1, and the surrounding documentation lives on docs.microsoft.com rather than in this tree.

## Maintenance, licensing and upgrade cost

The repository is not archived and the last push to master was on 2026-09-17, so the tree is receiving commits. That does not make the README current. Its release schedule stops at 10.1 and its repo status note still describes a migration to GitHub as in progress, so the documentation and the commit activity are not telling the same story. Anyone planning an upgrade should read release_notes/ and sfmc_release_notes/ in the repository rather than the README table.

The licence is MIT, which is permissive and places few conditions on reuse. One thing to check before assuming the whole build is MIT: the README states that the build container is based on an image containing Service Fabric dependencies that have not been open sourced or are included for technical constraints, and the repository carries a ThirdPartyNotices.txt at the top level. Those two files, not the licence line, are where the third-party obligations are described. This is a description of what the repository contains, not legal advice; read ThirdPartyNotices.txt yourself before redistributing a build.

Upgrade cost is dominated by the build. A runtime version change means another full build cycle at the times in the table, plus whatever the release notes say about the packages produced by -createinstaller. There is no incremental path documented in the README.

## Conclusion

Adopt this repository if you need to build the Linux Service Fabric runtime yourself, you have a machine with 16GB of RAM or more, roughly 70GB of free disk and Docker, and you are willing to wait an hour or more for the build. Do not adopt it if you only want a running cluster: the README points to the packaged installer path and to docs/install_packages_and_deploy_cluster.md for deployment, and the build tree is not that path. Before you commit, verify three things: that your machine meets the memory and disk figures in the build table, that your Docker daemon can resolve DNS if you sit behind a firewall, and that the runtime version you need appears in the release schedule. The last push to master was on 2026-09-17, so the tree is live, but the README itself still says development happens internally and that the move to GitHub is in progress.

## FAQ

### Is Service Fabric deprecated?

The README does not say the platform is deprecated. It does say the team is in the process of moving development to GitHub and that feature development continues internally until that move completes, and its release schedule table stops at version 10.1 in November 2023.

### What is Service Fabric used for?

It is a distributed systems platform for packaging, deploying and managing stateless and stateful distributed applications and containers at large scale, running on Windows and Linux across clouds, datacenters, regions or a single laptop.

### What are Service Fabric clusters?

The README does not define clusters directly. It points to docs/cluster_deployer_test.md for testing a local cluster and docs/install_packages_and_deploy_cluster.md for deploying a local cluster from a build, which is where the repository documents them.

### How do I install Service Fabric runtime for Windows?

This repository does not cover that. The README states that this is the Linux version of Service Fabric and that you need a Linux machine to build this project, so the Windows runtime is installed from elsewhere.

### What is Azure Service Fabric?

The README describes Service Fabric as a distributed systems platform for packaging, deploying and managing stateless and stateful distributed applications and containers at large scale, running on Windows and Linux, on any cloud, any datacenter, across geographic regions, or on your laptop.

## Sources

- [Issues](https://github.com/microsoft/service-fabric/issues)
- [License: MIT](https://github.com/microsoft/service-fabric/blob/master/LICENSE)
- [microsoft/service-fabric on GitHub](https://github.com/microsoft/service-fabric)
- [Project website](https://docs.microsoft.com/en-us/azure/service-fabric/)
- [README](https://github.com/microsoft/service-fabric/blob/master/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-service-fabric