Sites and apps
How to deploy an ASP.NET Core app without a VPS
In short
You can deploy an ASP.NET Core app without renting a server: upload the source code together with the .csproj file, and the platform detects .NET, builds the project and gives you a public HTTPS link. One condition matters: the app has to listen on the address the platform sets in the ASPNETCORE_URLS environment variable, not on localhost and not on a port written into the code such as 5000. You do not need HTTPS inside the app: the certificate and the secure connection come from the platform on the outside, and plain http is enough inside. Keep the connection string and API keys in environment variables rather than in appsettings.json.
The usual way to deploy a .NET app starts with shopping for ASP.NET Core hosting: rent a server, install the right .NET version, build the project, put nginx or IIS in front of it, issue a certificate and make sure the process comes back after a reboot. For a single site or a small C# service that is a couple of evenings spent on everything except the app itself.
Netrun takes that part away: you upload the folder with your source code, the platform finds the .csproj file, installs the right .NET version, builds the app and gives you a public HTTPS link. No server, no IIS, no manual certificate. Below are six steps between a folder of code and a working link, plus the three places where .NET projects usually trip up.
Ship the sources only#
The build happens on our side, so we need the source code together with the .csproj file, plus the .sln solution file if there is more than one project. Leave the bin and obj folders out of the archive: they are the result of a build on your machine, they inflate the upload and sometimes get in the way. NuGet packages do not need to travel either: they are restored from the dependency list in the project file.
Listen on the address from ASPNETCORE_URLS#
The platform sets the address and the port: the value arrives in the ASPNETCORE_URLS environment variable, and Kestrel reads it on its own without a line of code from you. Remove anything that overrides it: a UseUrls call in code, a Kestrel section with ports 5000 and 5001 in appsettings.json, a binding to localhost or 127.0.0.1. A hard-coded port and a localhost binding are the number one reason the link does not open later. The launchSettings.json file has no effect on publishing at all; it only matters when you run the app on your own machine.
Do not turn on HTTPS inside the app#
The secure connection and the certificate are handled by the platform on the outside, and the request reaches your app over plain http. That means the developer certificate, the UseHttpsRedirection call and an HTTPS endpoint in the Kestrel settings are not needed inside the project: they either do nothing or send visitors to an address that does not exist, and they end up in a redirect loop. The padlock in the browser stays where it is, because the platform provides it.
Move the connection string and keys into secrets#
Do not leave the database connection string, third-party API keys and tokens in appsettings.json: that file travels with the code and lands in the repository. During project setup Netrun asks for these values and injects them as environment variables in encrypted form. ASP.NET Core configuration already reads the environment on top of appsettings.json, and nested keys use a double underscore, for example ConnectionStrings__Default.
Decide where the data lives#
Files the app writes next to the code are recreated on the next publish. Anything that has to survive a code update, such as user uploads or a SQLite database, belongs in the persistent /data folder: you can see its contents on the Data tab in your dashboard and download, upload or delete files from there. If you need a full database such as PostgreSQL, run it as a separate service next to the app using your own docker-compose file. Projects that bring their own docker-compose file get no /data folder: there the persistent storage is the named volumes from your file.
Upload the code and grab the link#
Bring the project in one of two ways: as a ZIP archive with the sources, or by importing a GitHub repository, including a private one. You do not have to install the .NET SDK anywhere or run build commands yourself, it all happens on our side. Logs and publishing status are visible in the dashboard in real time, so a build error shows up immediately instead of as a blank page, and once the app is up you get a public HTTPS link.
The result: your C# site or API opens at an ordinary link you can send to anyone, with no server to rent and no certificates to configure. The free plan gives you one project, and a site on it sleeps while idle and wakes up by itself when someone opens the link, so the first visit after a pause is a little slower. If the app has to respond without delay around the clock, or you want to attach your own domain, the Pro plan fits; current prices and limits are shown in your dashboard. Try Netrun.
Common questions
Do I need to run dotnet publish before uploading?
No, upload the source code: the build runs on our side from the .csproj file. There is no need to include a compiled output or the bin and obj folders — they only make the archive bigger. You also do not need the .NET SDK installed anywhere on your side.
What if my solution has several projects?
Keep the .sln file together with the web project you want to run and the libraries it depends on, and the build works as usual. If the layout is complicated or several projects need to run, the safer option is your own Dockerfile next to the code: the platform uses it instead of the automatic build. Separate background workers are easier to run as separate Netrun projects.
Why does my ASP.NET Core site not open at the link?
Most often the app listens on the wrong address: the port is hard-coded in the code or in appsettings.json, or the binding points at localhost instead of 0.0.0.0. Remove your own values and let Kestrel read ASPNETCORE_URLS. The second common cause is HTTPS redirection inside the app, which sends visitors to an address that does not exist inside the container. The logs in your dashboard show which one it is.
Do I need a developer certificate or dotnet dev-certs?
No. The certificate and the secure connection are provided by the platform on the outside, and the request arrives over plain http inside. Commands like dotnet dev-certs are only for local development and change nothing when you publish.
Are Blazor, Minimal API and MVC supported?
Yes. For the platform this is an ordinary ASP.NET Core web app, and the project template makes no difference. Blazor Server and Blazor WebAssembly hosted together with a server work the same as MVC or Minimal API. A standalone Blazor WebAssembly client without a server can be published as a static site.
Can I use SQLite and Entity Framework?
Yes, but the database file has to live in the persistent /data folder, otherwise it is recreated on the next publish. Put the connection string into environment variables rather than appsettings.json. Migrations are easiest to apply at application startup: there is no SSH access into the container, so there is nowhere to run a one-off command.
Which languages and technologies are supported?
Python, Node.js, Go, Rust, Ruby, PHP, Java, .NET, Deno, Bun, Elixir, static sites and bash scripts. You can bring your own Dockerfile or docker-compose, but more often the stack is detected from your code automatically.
Do I need to know how to work with Docker?
No. Netrun detects which language your project uses and builds it for you. If you already have a Dockerfile or docker-compose, we support them, but you do not need to write them specially.
Where do I set tokens and other secret values?
Every project has a Secrets tab where you set the values from your code — for example the token from BotFather. We store them encrypted: you can see the variable names, but the values are shown to no one, including you.
Why does my website sometimes sleep?
On the free plan, websites sleep after being idle and wake up in a couple of seconds on the first request. On the Pro plan your project runs without sleeping.