The frustration was never .NET

When I wrote the first post, velixir ran .NET and nothing else. That was the whole pitch: a home for C# apps that did not cost enterprise money and did not make you fight a dashboard on a Tuesday night. I still use it every day, and I still believe in that pitch.

Here is the part I left out.

In the months after launch I kept wanting to ship things that were not .NET. A small Python service to summarise some logs. A Go tool I wrote in an afternoon to watch a queue. A friend's Rust side project I offered to host. Every time, I would get it running locally, reach for velixir out of habit, and then remember my own platform could not run it. So I would go host it somewhere else, on exactly the kind of platform I had built velixir to get away from.

That is an absurd position for a founder to be in. You start a hosting company because the existing options annoy you, and then you cannot use it for half your own projects.

The frustration was never about the language

So I went back and read my own first post. Every complaint in it was a hosting complaint. Fighting the dashboard on a Tuesday night. A bill you could not forecast. Egress fees that showed up weeks after the traffic did. Runtimes that felt like second-class citizens on somebody else's platform. Not one of those is a .NET problem. A Go developer opens the same opaque bill. A Python team pays the same egress to serve its own users. A Rails app fights the same console.

I built velixir because .NET hosting annoyed me. But the things that actually annoyed me had nothing to do with C#. I had built a general fix and then decided who was allowed to benefit from it.

So velixir runs high-scale web apps in any language now.

Any language, one pipeline

First-class today: Node.js, Deno, Python, Go, Ruby, PHP, Java, Elixir, Rust, .NET, and F#. If the build pipeline can detect and build your stack, you can deploy it.

The interface is your source. Connect a Git repo and the next push builds and ships. Prefer your terminal or your existing CI, and the velixir CLI or a GitHub Action does the same job. Whichever you pick, velixir reads what you pushed, works out the stack, and builds an OCI image. You never write a Dockerfile.

I owe you one honest correction, because in the first post I told you .NET went straight through dotnet publish with no buildpack in the way. That specific path is gone. .NET now goes through the same source-to-image pipeline as everything else. I would not have made that trade if it made .NET worse: publish still runs the way it should, and the output is still a lean image. What .NET lost is being a special case in my code, which is exactly the kind of thing that should not have been special. What it gained is that every improvement I make to the build now lands for .NET and the other ten stacks at the same time.

What did not change

Everything the first post promised for .NET is now true for every language on that list:

• Autoscaling is on by default, on every plan. You do not opt in, and you do not configure a fleet to survive a traffic spike.
• Managed Postgres and managed Valkey. Link one to an app and velixir injects DATABASE_URL and REDIS_URL for you. Point EF Core, Prisma, Ecto, Active Record, or sqlx at it and move on.
• Unmetered bandwidth, no egress fees. Serving your own users is not a line item.
• Atomic one-click rollback and deploy slots, so backing out a bad release is a click and staging one before you promote it is easy.
• Edge DDoS protection and free per-endpoint rate limiting.
• Billed hourly, in euros.

That list is the point. The pivot did not water anything down to make room for more languages. What a .NET developer got is what a Rust or Ruby or Elixir developer gets.

It runs in the EU, and it stays there

velixir runs only in the EU, in a region we call EU Central. Your app and your data stay under European jurisdiction and do not leave the EU. That is not a compliance checkbox I bolted on afterward. It is where the whole thing lives, and more of the conversations I have now open with someone asking exactly that: where does the data actually sit. On velixir the answer is short.

High availability, at the node level

When I say high availability I mean something specific, so here it is plainly. Your app can run with warm-standby replicas spread across separate worker nodes. If a node goes down, a standby on another node keeps serving while it recovers. It is not multi-region, and I am not going to dress it up as something it is not. It is redundancy across machines, which is the failure most people actually hit: one node having a bad day.

Try it without a card

You can sign up and deploy without a card. Every new account gets EUR 3.49 of starter credit, a full month of a Hobby app, and you do not enter payment details to get it. Add a card only when you want to top up, or to unlock the full first-month credit of up to EUR 14.99. For the rest of the numbers: a Hobby app is EUR 3.49 a month, managed Postgres starts at EUR 4.95, managed Valkey at EUR 2.45.

Same ask as last time

If you write .NET, nothing you liked went away. If you write anything else, the door that used to be closed is open.

So here is the actual ask. Take the thing you were about to host somewhere else, in whatever language it is written in, and push it to velixir instead. Fifteen minutes. If it does not build, tell me what broke and I will fix it. I have a personal stake in that Python log service and that Rust side project finally living on the platform I built.

Sign up at velixir.net.

Joe Connolly Founder, velixir