BTCPay Server removes the payment intermediary by making you the operator of a .NET 10 service

Accepting Bitcoin with no processor in the middle

A merchant who wants Bitcoin payments has two broad choices: hand the job to a hosted processor that sits between customer and shop, or run the processor themselves. BTCPay Server is the second option. Its README describes it as a free and open-source, self-hosted Bitcoin payment processor that lets merchants accept Bitcoin "directly, without fees or intermediaries."

That sentence carries the whole trade. No intermediary means no third party taking a cut and no third party between you and the payment. It also means nobody else runs the software. The server, its data and its upgrades belong to whoever deploys it.

The project splits its documentation along exactly that line. The README's Start Here section sends four audiences to four places: users to docs/users/README.md, operators to docs/operators/README.md, developers building integrations and plugins to docs/developers/README.md, and maintainers of the repository to docs/maintainers/README.md. A merchant evaluating it should read both the users and the operators guide, because self-hosting makes you both.

A C# solution split into Data, Client, Rating and plugin tooling

BTCPay Server is a .NET application, and the repository is organised as one Visual Studio solution, btcpayserver.sln, with several projects beside the main BTCPayServer/ web project. The Dockerfile's restore stage names the ones that ship in the server image: BTCPayServer.Abstractions, BTCPayServer.Common, BTCPayServer.Rating, BTCPayServer.Data and BTCPayServer.Client, plus Build/Common.csproj and Build/Version.csproj for shared build settings.

Two more projects sit outside that image. BTCPayServer.Tests holds the test suite, and BTCPayServer.PluginPacker is tooling for the plugin side of the project, which the developer guide covers under integrations and plugins.

For integration work, the documented interface is the Greenfield API, with its v1 reference on docs.btcpayserver.org. A shop, an invoicing system or a custom checkout talks to BTCPay Server through that API rather than through the database. The solution also carries a BTCPayServer.Client project, and anyone writing an integration in C# should check the developer guide for how it relates to Greenfield before writing raw HTTP calls.

The Docker image runs on .NET 10 and keeps its state in /datadir

The root Dockerfile is a two-stage build. The builder stage starts from `mcr.microsoft.com/dotnet/sdk:10.0.403-noble`, restores the projects, and runs `dotnet publish` into /app with a `CONFIGURATION_NAME` build argument that defaults to Release and a `GIT_COMMIT` argument passed through to the build. The runtime stage starts from `mcr.microsoft.com/dotnet/aspnet:10.0.14-noble` and installs a small set of tools: iproute2, openssh-client, ca-certificates and jq.

The part an operator has to get right is where state lives:

WORKDIR /datadir
WORKDIR /app
ENV BTCPAY_DATADIR=/datadir
ENV DOTNET_CLI_TELEMETRY_OPTOUT=1
VOLUME /datadir

These lines set `BTCPAY_DATADIR` to /datadir and declare it as a volume, while the application binaries live in /app. Replacing the container with a newer image swaps /app and leaves /datadir alone, provided you mounted it somewhere persistent. If you run the image without mapping that volume to storage you control, the server's data directory lives and dies with the container. The same block turns off .NET CLI telemetry. The image also copies a helper script, `Docker/btcpay-host`, to /usr/local/bin.

Building from source means matching the .NET 10 SDK

Outside Docker, the repository root has paired scripts for each platform: build.sh and build.ps1, run.sh and run.ps1, and publish-docker.sh and publish-docker.ps1. A global.json at the root controls which .NET SDK the build selects, and the Dockerfile's builder uses SDK 10.0.403, so plan on a .NET 10 SDK on any machine that builds this tree.

The README routes operators to docs/operators/README.md for deployment and developers to docs/developers/README.md, and those guides are the place to get the exact invocations. For a first look without installing anything, the project runs a public demo at mainnet.demo.btcpayserver.org.

The practical consequence is that a from-source build is a developer workflow, not an operator one. An operator deploying a store is better served by the image path and the operators guide. A developer writing a plugin needs the full SDK, the solution file and BTCPayServer.PluginPacker.

Self-hosting makes uptime, backups and upgrades your job

The "without intermediaries" pitch has a direct cost. There is no vendor running the server for you, so the work a hosted processor would do falls to the operator. The /datadir volume needs to persist and be backed up. The host needs to stay reachable for customers to pay. Upgrades happen when you apply them, not when a provider rolls them out.

That last point is concrete in the release history. v2.4.5 shipped on 2026-10-06, v2.4.6 on 2026-10-26 and v2.4.7 on 2026-10-29, three patch releases in one month, and the last push to master was on 2026-10-30. The project is under active development, and an operator who wants those fixes has to pull a new image and restart. The repository keeps a Changelog.md, a RELEASE-CYCLES.md and a RELEASE-CHECKLIST.md at the root, which are where to read what changed and how releases are cut.

A merchant who cannot commit to that routine gets the risks of self-hosting without the benefit. For that merchant, a hosted processor is the honest answer.

Security reports go through SECURITY.md, not the issue tracker

Vulnerabilities in a payment processor are not ordinary bugs, and BTCPay Server treats them separately. The README states that security vulnerabilities must be reported through the process in SECURITY.md, not as public issues. GitHub Issues and Discussions are for everything else, and there is a community chat at chat.btcpayserver.org.

For an operator this has two consequences. First, if you find something that looks exploitable on your own instance, filing it publicly is the wrong move. Second, security fixes arrive as releases like any other, so the upgrade discipline above is also your security posture. Watching the releases page and the changelog is part of running BTCPay Server.

The Bitcoin focus is also worth stating plainly. The README's description is about accepting Bitcoin. Before assuming any other asset, such as Monero or USDt, is handled, check the user and developer documentation, including the plugin material. Building a checkout around an asset the server does not accept is a failure you discover at the first customer payment.

BTCPay Server versus a hosted Bitcoin processor

The real alternative is not another self-hosted package but a hosted processor that runs the infrastructure for you. That model takes over uptime, upgrades and storage, and in exchange it sits between merchant and customer, which is the intermediary the BTCPay Server README says it removes.

The difference in approach is ownership. With BTCPay Server, the server, the data directory and the integration all live under your control, the code is MIT licensed, and you can read, modify and redeploy it, including plugins built with the project's own tooling. With a hosted service, none of that is yours, and neither is the operational work.

The MIT licence keeps the decision simple on the legal side: the software can be used commercially and modified, as long as the licence notice stays with it. The operational side is the part to think through before choosing.

Editorial conclusion

BTCPay Server suits merchants and developers who want to accept Bitcoin directly and are prepared to run a server: persist the /datadir volume, follow the 2.4.x patch releases, and integrate through the Greenfield API. It does not suit a merchant who wants someone else to carry uptime and upgrades, because removing the intermediary removes the party who would have done that work. Before committing, try the public demo at mainnet.demo.btcpayserver.org and read docs/operators/README.md to see what operating it involves.

Frequently asked questions

Official sources

1. btcpayserver/btcpayserver on GitHub
2. License: MIT
3. Project website
4. README
5. Releases