A Single-Project Monolith Deployment is the simplest production story in modern software. One .NET 10 application produces one artifact — a single Docker image — that contains the UI, the API, the domain logic, and the persistence code. That image runs on one server, talks to one database, and is shipped by one pipeline. There is no orchestration layer to operate, no service-to-service networking to debug, and no fleet of containers to coordinate. You build, you publish, you go home.
That simplicity is the point. Every piece of deployment infrastructure that microservices require — Kubernetes, service mesh, distributed tracing, API gateways — exists to manage a problem the single-project monolith does not have. This article walks through the concrete deployment setup and shows how far one app on one server can take you.
Why a Single-Project Monolith Is Trivial to Deploy
Deployment complexity is directly proportional to the number of deployable units. A monolith has one. That single fact eliminates an entire category of operational work: coordinated releases vanish (there is nothing to coordinate), version skew disappears (there is one version), and rollbacks become a single image tag swap. The failure domain is one process, so the runbook is short enough to fit on a page.
This matters most for small teams and freelancers, who are exactly the people who can least afford a Kubernetes cluster as a permanent fixture. A single-project monolith puts production within reach of one person with one virtual machine — and that is a feature, not a limitation.
Shipping a Single-Project Monolith in One Container
Containerizing a single-project monolith is a two-stage Dockerfile: build with the SDK, then run on the runtime image. Because there is exactly one project, the build stage publishes the whole application in one command:
FROM mcr.microsoft.com/dotnet/sdk:10.0 AS build
WORKDIR /src
COPY . .
RUN dotnet restore src/MyApp/MyApp.csproj
RUN dotnet publish src/MyApp/MyApp.csproj -c Release -o /app/publish
FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS final
WORKDIR /app
COPY --from=build /app/publish .
EXPOSE 8080
ENTRYPOINT ["dotnet", "MyApp.dll"]Run it with a single docker compose file that defines the app and its database, and you have a complete production topology — one app, one server, one container. Health checks at /health tell the container runtime whether the app is alive, and the reverse proxy forwards a single port. There is no service mesh configuration to write because there are no services to wire together.
CI/CD for a Single-Project Monolith
The pipeline is as short as the deployment. On every push, the CI job restores, builds, runs the test project, publishes, builds the image, and pushes it to a registry. A deploy job then pulls the image on the server and restarts the container. In YAML, the essence is four steps:
steps:
- name: Restore and build
run: dotnet restore src/MyApp && dotnet build --no-restore -c Release
- name: Test
run: dotnet test tests/MyApp.Tests --no-build -c Release
- name: Publish
run: dotnet publish src/MyApp -c Release -o out
- name: Deploy over SSH
run: scp -r out/ deploy@server:/app && ssh deploy@server "sudo systemctl restart myapp"Structured logging, environment-based configuration, and a health check complete the picture. When the app misbehaves, one set of logs from one process is the whole investigation surface. There is no correlation ID to stitch together across services — the correlation ID is the request ID from a single server.
Two operational details complete the picture. Secrets never live in the image: connection strings, JWT signing keys, and API credentials come from environment variables or a secret manager injected at run time, so the same image moves from staging to production unchanged. And one simple alerting rule — the health check fails, or the error rate rises above a threshold — is enough to wake you when something is wrong, because there is exactly one process whose metrics matter. Monitoring a monolith is reading one dashboard, not correlating twenty.
This is the deployment story that small teams and independent developers actually live with every day. The monolith does not just reduce deployment work to a few commands; it reduces the planning, coordination, and post-release anxiety of deployment to almost nothing. When every change is one artifact and every rollback is one tag, shipping becomes boring — and boring is exactly what you want production to be.
When One Server Is Not Enough
The honest question is what happens when traffic outgrows one machine. The answer is boring and good: you run two instances of the same image behind a load balancer. The monolith does not need to become microservices to scale horizontally; it needs a shared database and a SignalR backplane for real-time features, both of which are standard infrastructure. Only when a specific component must scale independently — a genuinely hot path — do you extract it, and even then you extract exactly one service and keep the rest a monolith.
Key Takeaways
- A Single-Project Monolith Deployment is one image, one server, one database, and one pipeline.
- One deployable unit eliminates coordinated releases, version skew, and complex rollbacks.
- A two-stage Dockerfile and a four-step CI/CD pipeline ship the entire application.
- Horizontal scaling means more instances of the same image, not a new architecture.
- Every Indotalent product deploys exactly this way — complete .NET 10 source code for $21 each.
FAQ
Can a single-project monolith really handle production traffic? Yes. Most business applications are read-mostly and fit comfortably on one server. When more capacity is needed, additional instances of the same image scale horizontally behind a load balancer.
Do I need Docker or Kubernetes to deploy a monolith? Docker helps, Kubernetes is optional. The image runs fine on a single virtual machine managed by a simple service; an orchestrator is only worth its cost when you have many deployable units, which a monolith does not.
How do I roll back a bad monolith release? Roll back by pointing the server at the previous image tag and restarting. There is one artifact to revert and no chain of interdependent services to coordinate.
When should I extract a service from the monolith? When a specific component has a demonstrable independent scaling or ownership requirement. Until then, run more instances of the same image — extraction is a one-way door, so delay it until the evidence is real.