The languages with their own guides — Node, Python, Bun, Java, PHP, Go, Rust — aren't the whole list. Falix also ships applications for C#, Deno, Dart, Elixir, and Lua. They're less common, so this guide gives each one a compact, honest section: what file it runs, how dependencies work, and the one thing most likely to trip you up.
🎯 Good to know: If any of these will serve web traffic, the universal port rules — read
SERVER_PORT, bind0.0.0.0— apply exactly as they do everywhere; see Your first web app.
| At a glance | |
|---|---|
| You need | A Falix server running the application you want |
| Plan | Any — on free it runs while your session timer has time left, premium runs 24/7 |
| No server yet? | Create your first app server |
C# / .NET
What runs: on start, the application changes into your project directory, runs dotnet restore, then dotnet run against your project file. Two variables on the Settings page point it at your code: Project location (default /home/container) and project file (for example MyApp.csproj).
Dependencies: dotnet restore reads the PackageReference entries in your .csproj and fetches them on every start — so you add a NuGet package by editing the .csproj and restarting. There's no Packages page for C#; the restore step is your install step.
Version: .NET 2.1 through 10 are selectable in Settings (default 8).
Gotcha: the two variables have to match your layout exactly. If Project location doesn't contain your project, or the project file name is wrong, restore and run fail before your code ever executes.
💡 Tip: The first restore is also slow — that's normal, not a hang.
Deno
What runs: ./deno run <your JS file> — the entry file variable defaults to app.js, and the deno binary is downloaded into your server folder when the application installs.
Dependencies: Deno resolves imports directly from your source (URL, npm:, and jsr: specifiers) and caches them on first run — there's no separate install file to maintain. If your project keeps a deno.json, the Packages page can manage its dependencies for you (it runs deno add under the hood).
Gotcha (read this before you build a Deno web app): Deno is secure by default, which means that without permission flags, any network or environment access is denied. The default startup runs deno run with no --allow-* flags, so a script that tries to read an env var or open a port simply fails. Adding flags like --allow-net --allow-env means editing the full startup command — and editing the startup command is a premium-only feature. On a free plan, plan around Deno programs that don't need those permissions, and keep your expectations straight before you get attached to a Deno web server here.
Dart
What runs: dart pub get followed by dart run. Dart expects a standard package layout — a pubspec.yaml at the root and your entry point under bin/.
Dependencies: dart pub get reads pubspec.yaml and installs on start. The Dart application also has a Packages page in the server menu: search for a package and press Install, and it runs dart pub add, updating pubspec.yaml for you. Restart afterwards.
Gotcha: a single loose .dart file won't run — dart run needs the real package structure. Make sure you have a valid pubspec.yaml and a bin/ entry point, not just a script.
Elixir
What runs: mix deps.get followed by mix run --no-halt. The --no-halt keeps the VM alive so a long-running app (a Phoenix server, a GenServer supervision tree) doesn't exit the moment it finishes booting.
Dependencies: mix deps.get reads the deps in your mix.exs and fetches them on start. There's no Packages page for Elixir; declare dependencies in mix.exs.
Gotcha: you need a real Mix project — a mix.exs at the root. A bare .exs script isn't enough for mix run, and without --no-halt behaviour to rely on, a project that only runs setup and returns will stop. Structure it as a proper application.
Lua (Luvit)
What runs: ./luvit <your Lua file> — the entry variable defaults to app.lua, run on the Luvit runtime.
Dependencies: there's no Packages page for Lua. Keep your libraries alongside your code in the server folder so require can find them.
Gotcha: Luvit is not plain Lua or LuaJIT — it's an async, event-driven runtime (think Node, but Lua). Code written for a synchronous Lua interpreter may need Luvit's own APIs for I/O and networking. Make sure your entry file name matches the Lua file variable, or nothing starts.
Quick reference
| Runtime | Entry point | Dependencies | Gotcha |
|---|---|---|---|
| C# / .NET | dotnet run against your project file |
dotnet restore reads the .csproj on every start |
Project location and project file must match your layout exactly |
| Deno | ./deno run on the entry file (default app.js) |
Resolved from source and cached; deno.json via Packages |
Secure by default — permission flags need the startup command (premium-only) |
| Dart | dart run (needs pubspec.yaml + bin/) |
dart pub get from pubspec.yaml; Packages page |
A loose .dart file won't run without the package structure |
| Elixir | mix run --no-halt |
mix deps.get from mix.exs |
Needs a real Mix project; a bare .exs isn't enough |
| Lua (Luvit) | ./luvit on the entry file (default app.lua) |
No Packages page — keep libraries alongside your code | Luvit is async/event-driven, not plain Lua or LuaJIT |
A different app, and what a reinstall wipes
Each runtime takes its entry point from a variable (C#'s project file, Deno's and Lua's entry-file variables) or a fixed project layout (Dart's bin/, Elixir's Mix project) — change that and you change what runs. To run a genuinely separate app on the same server, though, reach for Instances: each is its own application, files, and startup, switched like a save slot.
⚠️ Heads up: Whatever a runtime installs for you — Dart's and Elixir's package folders, Deno's module cache, C#'s restored packages — isn't yours to keep. A reinstall, or switching the server to a different application, can wipe your files along with those folders. You don't restore them by hand: the install step (
dart pub get,mix deps.get,dotnet restore, Deno's on-run fetch) runs again on the next start and rebuilds them. Guard your own source and data — a managed database is the safe home for data.
When things go wrong
- Starts, then stops with no error — a program that runs and returns exits cleanly, and the server shows as stopped. That's normal for a one-shot job; a server or bot stays up because something keeps the process alive. See My app won't start.
- Web app unreachable — check the port and bind address against the web app rules, then I can't reach my app. (For Deno, remember the permission gotcha above.)
- Killed under load, exit code 137 — memory: Out of memory.