Build boundary
Local by choice
AUGUST 27, 2026 · BlackSails team · 5 min read
Why BlackSails still supports local builds
EngineeringRemote builds remove local SDK setup and are a natural fit for teams that want an isolated, repeatable pipeline. They are not the right default for every repository.
BlackSails keeps its local artifact contract and also integrates with Runnable when a managed build is the better fit. Both paths hand the same completed output to the deployment platform.
01
Keep the SDK decision with the project
The repository can pin an SDK, carry workload requirements, and depend on local package sources or build properties. Recreating every variation in a proprietary builder adds another place for the project to drift.
Running dotnet publish locally keeps those decisions beside the code and makes failures available in the same terminal developers already use to fix them.
02
Upload output, not ambiguity
In the local path, BlackSails packages the successful Linux x64 publish output and verifies the archive before upload. The control plane does not need source access to decide how the application should compile.
This is a smaller security and operations surface: source stays where you work, while the platform stores only what it needs to release and run the service.
03
A clear line of responsibility
Local build does not mean local production. BlackSails still owns deployment state, environment configuration, runtime isolation, health checks, logs, and the public endpoint.
Whether the artifact is built locally or by Runnable, BlackSails owns how that finished build becomes a service.
The best build environment may be the developer machine or an isolated Runnable runner. BlackSails lets teams choose while keeping the handoff to production explicit.