Hosting · .NET 8 · 9 · 10
ASP.NET Core hosting on the platform we use for our own apps
Upload the output of dotnet publish. We start it, check its health, and move traffic to it. You don’t maintain a Linux server or write a systemd unit.
- 0.5 vCPU, 256 MB, 5 GB
- from €3/mo
- LTS ready
- .NET 10
- downtime deploys
- Zero
- and WebSockets
- SignalR
- uptime SLA
- 99.9%
Deploys, patching, and scaling
How a build gets to production, who keeps the runtime up to date, and what happens when traffic is higher than you planned for. The rest is in the specifications below.
Rollouts
Deploys without downtime
A deploy starts the new build next to the running one and waits for its health endpoint. Traffic moves only after the check passes, and then the old instance is drained. If the check never passes, the rollout stops and users stay on the current version.
- No requests move until the readiness check passes
- The old instance finishes its open connections before it stops
- A failed check rolls back automatically, at any hour
$ dotnet publish -c Release$ intrvll deploy ./bin/Release/net10.0/publish uploading 18.4 MBstarting v87 (v86 still serving)health GET /health/ready 503health GET /health/ready 200traffic v86 -> v87drain v86 stopped (0 in flight) live in 24.8s - 0 failed requests
Runtime
We patch .NET, you choose the major version
We apply .NET security and patch releases on our schedule, with no work on your side. You choose the major version per app, so an app on .NET 10 LTS stays on 10 until you change it. Kestrel runs behind our proxy, which terminates HTTP/3 and WebSockets.
- Patch releases applied without a redeploy from you
- .NET 8, 9, and 10 LTS available side by side
- SignalR and WebSockets with sticky routing and a Redis backplane
{ "runtime": "dotnet:10-lts", "entrypoint": "Astrava.Api.dll", "health": "/health/ready", "websockets": true, "sticky": true // SignalR "env": { "ConnectionStrings__Default": "@postgres.url" }}
Dynamic Resource Scheduling
Resources that follow the load, within your limits
Fixed sizes cost less when load is steady. When it isn’t, turn on DRS for €10 a month. The scheduler gives the app more CPU and memory when it needs them and takes them back afterwards. You pay for what it used, by the hour, at the slider rates.
- No throttling during a spike, and no ticket to open
- Metered per vCPU-hour and GB-hour, only while used
- Hard limits you set cap both the app and the bill
limits 4 vCPU / 8 GB €10.00 base 08:00-17:00 0.5 vCPU / 768 MB17:12-17:58 2 vCPU / 2.75 GB 0h 46m18:00-23:59 0.5 vCPU / 768 MB billed per hour, as usedlimit 8 GB not reached
From dotnet publish to serving traffic
- 01
Publish the app
We only need a framework-dependent publish. You don’t build a container or maintain a Dockerfile.
dotnet publish -c Release - 02
Describe it once
Set the runtime, entrypoint, and health endpoint. Everything else has a default you can change later.
runtime: dotnet:10-lts - 03
Connect it to CI
The same deploy command runs from a GitLab or GitHub job, so merges to your release branch deploy automatically.
intrvll deploy ./publish - 04
Deploy
We run the health check, move traffic, and drain the old instance. If any step fails, the previous version keeps serving.
Fixed sizes or DRS
There are no plans. Set the CPU, memory, and storage and the price updates as you go. Or turn on DRS and dynamic storage and pay by the hour for what the app uses. Deploys, builds, health checks, and seats aren’t charged separately.
Compute
The .NET process gets more CPU and memory when it needs them and releases them afterwards, up to the hard limits you set.
Storage
Instead of a fixed size, we grow the storage before it fills and shrink it when data is deleted.
Transfer not meteredHealth-gated rolloutsRuntime patched by usTLS issued and renewed
Monthly estimate
- 0.5 vCPU€2.00
- 256 MB memory€0.50
- 5 GB storage€0.50
€3.00/mo
Net. 19% VAT is added on the invoice. Changes are prorated to the day, with no minimum term.
Set it up in the consoleMore than 16 vCPU, 32 GB of memory or 100 GB of storage? Talk to us.
Full specifications
Everything the platform includes. If a feature isn’t listed here, we don’t offer it.
Runtime
- .NET versions
- 8 · 9 · 10 LTS
- Web server
- Kestrel behind our proxy
- Version pinning
- Per app, per major
- Patching
- Applied by us
- Deploy artifact
- Zip or CI push
Serving
- Protocols
- HTTP/2 · HTTP/3
- WebSockets
- Yes, sticky routing
- SignalR
- Redis backplane supported
- gRPC
- Yes
- TLS
- Auto-issued, auto-renewed
Operations
- Rollout
- Health-gated
- Rollback
- One click
- Health checks
- Liveness + readiness
- Alerts
- Email or webhook
- Log retention
- 30 days
- Uptime SLA
- 99.9%
Around the app
- Database
- Managed PostgreSQL add-on
- Secrets
- Encrypted, injected at boot
- Static assets
- Served from opncdn
- Scaling
- Fixed sizes or DRS
- Execution
- EU hardware we own
Common questions
Do I need to containerise anything?
No. You give us the output of dotnet publish and we run it, with no Dockerfile or registry. If you already have a container workflow you’d like to keep, tell us, but you don’t need one.
Which .NET versions can I run?
.NET 8, 9, and 10 LTS, pinned per app. We apply patch releases within your major version. A major upgrade never happens on its own. You move when your code is ready.
Does SignalR work behind your proxy?
Yes. Our proxy terminates WebSockets, and sticky routing keeps each connection on the instance that owns it. For more than one instance, use the managed Redis backplane and scale-out works as described in Microsoft’s documentation.
How is DRS different from setting the sliders higher?
Fixed sizes cost less when load is steady, so use them if it is. DRS is for load that spikes. For €10 a month, the scheduler gives the app CPU and memory when it asks, up to the hard limits you set, and bills only the hours they were used. A one-hour peak is billed as one hour, not a month.
And dynamic storage?
For €5 a month, storage is no longer a fixed size. We grow the volume before it fills and shrink it when data is deleted, and bill what it used by the hour at €0.10 a GB a month. It works with fixed sizes or with DRS.
What happens to a deploy that never becomes healthy?
It’s stopped. The old instance keeps serving every request, and the failing health response appears in the deploy log. Visitors never reach the bad build.
Can I run background services and hosted workers?
Yes. An IHostedService runs as part of the app. A separate worker process also works and deploys on the same cycle. If it’s heavy enough to slow down request handling, give it its own app.
Where does the data live?
On hardware we own in the EU. The app, the managed PostgreSQL add-on, the logs, and the backups all stay there. Nothing is transferred to the US, and there’s no third-party platform underneath ours.
We run our own .NET apps here
Our console, billing, and provisioning are ASP.NET Core apps on this platform. Send us a build and an appsettings file and we’ll tell you whether it will run here.