Forem: Ali Mahdavi

Deploying ASP.NET Core Apps on the Flux Network Using Deploy With Git

Ali Mahdavi — Wed, 01 Apr 2026 12:01:19 +0000

ASP.NET Core is a popular framework for building modern, cross-platform web applications and APIs. Deploying these apps on the decentralized Flux Network is simple and efficient with the Deploy With Git feature. This guide explains how to deploy a minimal "Hello World" ASP.NET Core application directly from a Git repository. Flux automatically detects the project, installs the required .NET SDK, builds the application, and runs it across its global network of nodes.

No Dockerfiles or complex setup are needed. Just push your code to GitHub, and Flux handles the entire process.

How Flux Handles ASP.NET Core Deployment

Flux makes .NET deployments straightforward:

It scans for .csproj files to identify .NET projects.
It reads the TargetFramework from the .csproj file (this example uses .NET 8.0 LTS).
It installs the matching .NET SDK.
It runs dotnet restore to fetch dependencies.
It executes dotnet publish -c Release -o ./publish to compile the app.
It starts the application with the specified runtime command.

The ASP.NET Core app binds to 0.0.0.0:$PORT using the ASPNETCORE_URLS environment variable, which Flux sets automatically. The app then becomes available on the Flux network.

Important note: You must set the RUN_COMMAND environment variable to tell Flux which DLL to execute after publishing.

Prerequisites

Before starting, make sure you have:

A public GitHub repository (or a private repository with a GitHub personal access token).
A FluxCloud account.
Basic knowledge of Git and ASP.NET Core.

Step-by-Step Deployment

1. Prepare and Push Your Project to GitHub

Push your ASP.NET Core project to GitHub. Use a public repository for the easiest setup, or provide a personal access token for private repositories.

2. Register the Application on FluxCloud

Go to the FluxCloud dashboard and select Deploy with Git.
Log in or create a new FluxCloud account.
Choose your preferred plan and click Start Deploying.
Enter the following details:
- Repository URL
- Branch name
- Path to the project (for example, deploy-aspnet-core/ if inside a monorepo)
- GitHub personal access token (only required for private repositories)
Click Continue and complete the configuration form.
Review the settings and click Register.

Flux will build and deploy your application across multiple nodes. When finished, your app will be live at:

https://YOUR-APP-NAME.app.runonflux.com

Configuration Settings

Configure these fields during the registration process.

Basic Information

Application Name: Use 3 to 32 characters consisting of lowercase letters, numbers, and hyphens only.
Contact Email: Provide an email for deployment notifications and alerts.

Application Port

Set the Application Port to 8080. This must match the port your ASP.NET Core application listens on.

Custom Domain (Optional)

You may add your own custom domain. After deployment, update your DNS records to point to Flux.

Advanced Options

Auto-Update Polling Interval: Controls how often Flux checks for repository updates. The default is 24 hours. For faster updates, use GitHub webhooks.
Enterprise App: Enable this option for extra security. It encrypts your app specification and environment variables and limits deployment to verified ArcaneOS nodes.

Environment Variables

Set the following variables as needed:

Variable Name	Description	Required	Default Value
RUN_COMMAND	The command to start the app	Yes	(none)
PORT	Port the server listens on	No	8080
DOTNET_VERSION	.NET SDK version to use	No	Detected from csproj (8.0)
BUILD_COMMAND	Custom build command	No	dotnet publish -c Release -o ./publish
WEBHOOK_SECRET	Secret for GitHub webhook authentication	No	(none)

Critical requirement: Set RUN_COMMAND to dotnet deploy-aspnet-core.dll. This tells Flux the correct entry point for your published application.

Enabling Automatic CI/CD with GitHub Webhooks

To redeploy automatically on every code push:

After your app is running, copy the webhook URL from the Flux dashboard (format: https://YOUR-APP-NAME-9001.app.runonflux.io/webhook).
In your GitHub repository, go to Settings > Webhooks > Add webhook.
Set the following:
- Payload URL: Paste the Flux webhook URL.
- Content type: Select application/json.
- Secret: Use the same value as your WEBHOOK_SECRET environment variable.
- Events: Choose "Just the push event".
Save the webhook.

Every git push to the selected branch will now trigger an automatic redeployment, usually within about 2 minutes. Flux rolls back automatically if the build fails.

Resources

FluxCloud Dashboard: https://cloud.runonflux.com
Deploy With Git Overview: https://docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/
Deploying .NET Apps on Flux: https://docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/guides/deploying-dotnet
GitHub Webhooks Guide: https://docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/ci-cd/github-webhooks
Flux Network: https://runonflux.com

This method allows you to deploy ASP.NET Core applications quickly and reliably on the Flux Network. With only a Git repository, your app becomes globally distributed and highly available in minutes. Fork the example repository and try deploying your own ASP.NET Core app today.

Deploying Blazor WebAssembly Apps on the Flux Network Using Deploy With Git

Ali Mahdavi — Wed, 01 Apr 2026 11:54:07 +0000

Blazor WebAssembly offers a powerful way to build interactive web applications with C# that run directly in the browser. Hosting these apps on a decentralized cloud platform like the Flux Network becomes straightforward with the Deploy With Git feature. This guide walks you through deploying a minimal hosted Blazor WebAssembly "Hello World" application from a Git repository. Flux automatically detects the .NET project, handles dependencies, builds the app, and serves it across its global network of nodes for high availability and resilience.

No Docker knowledge or complex CI/CD pipelines are required. Simply push your code to GitHub, and Flux takes care of the rest.

Understanding the Hosted Blazor WebAssembly Model

This deployment example uses the hosted Blazor WebAssembly model. In this setup:

An ASP.NET Core server project hosts and serves the compiled WebAssembly client.
The client runs in the user's browser, while the server delivers the necessary static files and handles any backend logic if needed.

The server project is responsible for serving the published WebAssembly assets. Flux identifies .NET projects through the presence of .csproj files.

How Flux Handles Blazor WebAssembly Deployment

Flux streamlines the process for .NET applications:

It scans for .csproj files and reads the TargetFramework (this example targets .NET 8.0 LTS).
It installs the matching .NET SDK.
It runs dotnet restore to fetch dependencies.
It executes dotnet publish -c Release -o ./publish to build both the server and the WebAssembly client.
It starts the application using the specified runtime command.

The ASP.NET Core server automatically binds to 0.0.0.0:$PORT using the ASPNETCORE_URLS environment variable provided by Flux. The published app serves the Blazor WebAssembly files as static content.

Important note: Because the publish output folder contains multiple DLLs, you must explicitly set the RUN_COMMAND environment variable to tell Flux which assembly to execute.

Prerequisites

Before starting, ensure you have:

A public GitHub repository (or a private repository with a GitHub personal access token).
A FluxCloud account.
Basic familiarity with Git and .NET project structures.

Step-by-Step Deployment

1. Prepare and Push Your Project to GitHub

Clone or create your repository and push the Blazor WebAssembly project. Keep the repository public for simplicity, or prepare a personal access token with repository read permissions if using a private repo.

2. Register the Application on FluxCloud

Visit the FluxCloud dashboard at https://cloud.runonflux.com/apps/register and select Deploy with Git.
Log in or create a new FluxCloud account.
Choose your preferred plan and click Start Deploying.
Provide the following details:
- Repository URL
- Branch name
- Path to the project (for example, deploy-blazor-wasm/ if located inside a monorepo)
- GitHub personal access token (only for private repositories)
Click Continue and fill in the configuration form.
Review all settings and click Register.

Flux will build and deploy the application across multiple nodes. Once complete, your app becomes accessible at:

https://YOUR-APP-NAME.app.runonflux.com

Configuration Settings

Configure these fields carefully during registration.

Basic Information

Application Name: Use 3 to 32 characters consisting of lowercase letters, numbers, and hyphens only.
Contact Email: Provide an email address for deployment notifications and alerts.

Application Port

Set the Application Port to 8080. This value must match the port your ASP.NET Core server listens on so that Flux can configure the proper port mapping.

Custom Domain (Optional)

You can specify your own domain. After registration, configure your DNS records to point to Flux. Detailed instructions are available in the Flux documentation for custom domain setup.

Advanced Options

Auto-Update Polling Interval: Controls how frequently Flux checks the repository for updates. The default is 24 hours. For faster updates, configure GitHub webhooks instead.
Enterprise App: Enable this for added security. It encrypts your application specification and environment variables and restricts deployment to verified ArcaneOS nodes.

Environment Variables

Set these variables to ensure correct operation:

Variable Name	Description	Required	Default Value
RUN_COMMAND	The command to start the app	Yes	(none)
PORT	Port the server listens on	No	8080
DOTNET_VERSION	.NET SDK version to use	No	Detected from csproj (8.0)
BUILD_COMMAND	Custom build command	No	dotnet publish -c Release -o ./publish
WEBHOOK_SECRET	Secret for GitHub webhook authentication	No	(none)

Critical requirement: Set RUN_COMMAND to dotnet deploy-blazor-wasm.dll. This points Flux to the correct entry point after publishing.

Enabling Automatic CI/CD with GitHub Webhooks

For instant deployments on every code push:

After your app is running, copy the webhook URL from the Flux app dashboard (it follows the format https://YOUR-APP-NAME-9001.app.runonflux.io/webhook).
In your GitHub repository, go to Settings > Webhooks > Add webhook.
Configure the webhook as follows:
- Payload URL: Paste the Flux webhook URL.
- Content type: Select application/json.
- Secret: Enter the same value you set for the WEBHOOK_SECRET environment variable in Flux.
- Events: Choose "Just the push event".
Save the webhook.

From now on, every git push to the selected branch triggers an automatic redeployment (typically within about 2 minutes). If the new build fails, Flux automatically rolls back to the previous working version.

Resources

FluxCloud Dashboard: https://cloud.runonflux.com
Deploy With Git Overview: https://docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/
Deploying .NET Apps on Flux: https://docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/guides/deploying-dotnet
GitHub Webhooks Guide: https://docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/ci-cd/github-webhooks
Flux Network: https://runonflux.com

This approach makes deploying Blazor WebAssembly applications simple, scalable, and decentralized. With just a Git repository, you can have a globally distributed Blazor app running in minutes on the Flux Network. Start experimenting today by forking the example repository and deploying your own version.

Deploying Flask to a Decentralized Cloud

Ali Mahdavi — Fri, 27 Mar 2026 15:37:54 +0000

I recently started exploring decentralized infrastructure as a middle ground: "push-to-deploy" simplicity, but with the resilience of a global network and much lower costs. I used Flux Cloud and their "Deploy with Git" feature to get a Flask app live across a global network of independent nodes.

Here is the technical breakdown of the setup and why this architecture is a great fit for Flask.

Why a Decentralized Backend for Flask?

Native High Availability: Instead of sitting in one data center, your Flask app is spawned across multiple independent global nodes. If one provider goes down, the network routing keeps your site or API live.
Cost Efficiency: Since it is a peer-to-peer resource network, the overhead is much lower than traditional centralized providers. You get more CPU/RAM for your money.
Automated GitOps: You get the standard workflow—push to GitHub/GitLab, and the network handles the build and deployment automatically.

Step 1: Prepare your Flask Project

The network needs to know how to handle your Python environment. Make sure your project has a standard requirements.txt.

For production, it is best to use a WSGI server. Ensure your configuration or start script uses something like Gunicorn:

"scripts": {
"start": "gunicorn app:app --bind 0.0.0.0:8000"
}

Step 2: Configure the Deployment

To keep things simple, I used the official configuration boilerplate. This ensures that the network knows which port to listen on and how to handle the Flask lifecycle without manual server management.

You can find the specific Flask config guide here.

Step 3: Link and Deploy

Go to the Flux Cloud Dashboard.
Select Deploy with Git.
Paste your repository URL.
The network detects the Python environment, installs your requirements, and propagates the app to global nodes.

Once live, any push to your main branch triggers a fresh build. If a deployment fails health checks, it automatically stays on the last working version.

Resources

Flask Deployment Guide: View on GitHub
Official Documentation: Flux Deploy with Git Introduction

Deploying FastAPI to a Decentralized Cloud

Ali Mahdavi — Fri, 27 Mar 2026 14:54:41 +0000

If you have been building with FastAPI lately, you know it is one of the fastest ways to get a high-performance API running. However, once you start scaling or need high availability, the hosting bills on traditional platforms can grow surprisingly fast.

I recently started looking into decentralized alternatives as a way to get "push-to-deploy" simplicity with better global resilience and much lower overhead. I used Flux Cloud and their "Deploy with Git" feature to get a FastAPI app live across a global network of independent nodes.

Here is the technical breakdown of the setup and why this architecture is a great fit for Python backends.

Why a Decentralized Backend for FastAPI?

Native High Availability: Instead of sitting in one data center, your FastAPI app is spawned across multiple independent global nodes. If one provider goes down, the network routing keeps your API live.
Cost Efficiency: Since it is a peer-to-peer resource network, you aren't paying for massive corporate markup. It is often a fraction of the cost of standard PaaS providers.
Automated GitOps: You get the standard workflow—push to GitHub/GitLab, and the network handles the build and deployment automatically.

Step 1: Prepare your FastAPI Project

The network needs to know how to handle your Python environment. Make sure your project has a standard requirements.txt.

Since FastAPI needs an ASGI server to run, ensure your configuration or start script uses something like Uvicorn:

"scripts": {
"start": "uvicorn main:app --host 0.0.0.0 --port 8000"
}

Step 2: Configure the Deployment

To keep things simple, I used the official configuration boilerplate. This ensures that the network knows which port to listen on and how to handle the FastAPI lifecycle without manual server management.

You can find the specific FastAPI config guide here.

Step 3: Link and Deploy

Go to the Flux Cloud Dashboard.
Select Deploy with Git.
Paste your repository URL.
The network detects the Python environment, installs your requirements, and propagates the app to global nodes.

Once live, any push to your main branch triggers a fresh build. If a deployment fails health checks, it automatically stays on the last working version.

Resources

FastAPI Deployment Guide: View on GitHub
Official Documentation: Flux Deploy with Git Introduction

Moving my Django backends to decentralized nodes: A Technical Guide

Ali Mahdavi — Fri, 27 Mar 2026 14:52:07 +0000

I’ve been testing out decentralized infrastructure lately as a way to get "push-to-deploy" simplicity with better global resilience and lower costs. I used Flux Cloud and their "Deploy with Git" feature to get a Django app live across a global network of independent nodes.

Here is the breakdown of the setup and why this architecture is a solid alternative to traditional hosting.

Why a Decentralized Backend for Django?

High Availability by Default: Instead of sitting in one data center, your Django app is spawned across multiple independent global nodes. If one goes down, the network routing keeps your API or site live.
Cost Savings: Since it is a peer-to-peer resource network, the costs for CPU and RAM are significantly lower than traditional providers.
Automated GitOps: You get the standard workflow—push to GitHub/GitLab, and the network handles the build and deployment automatically.

Step 1: Prepare your Django Project

The network needs to know how to handle your Python environment. Make sure your project has a standard requirements.txt and that your settings.py is configured to handle allowed hosts and static files correctly.

Ensure your project has a start script or uses a WSGI server like Gunicorn in your configuration:

"scripts": {
"start": "gunicorn myproject.wsgi:application --bind 0.0.0.0:8000"
}

Step 2: Configure the Deployment

To keep things simple, I used the official configuration boilerplate. This ensures that the network knows which port to listen on and how to handle the Django lifecycle without manual server management.

You can find the specific Django config guide here.

Step 3: Link and Deploy

Go to the Flux Cloud Dashboard.
Select Deploy with Git.
Paste your repository URL.
The network detects the Python environment, installs your requirements, and propagates the app to global nodes.

Once live, any push to your main branch triggers a fresh build. If a deployment fails health checks, it automatically stays on the last working version.

Resources

Django Deployment Guide: View on GitHub
Official Documentation: Flux Deploy with Git Introduction

How to Deploy SvelteKit to a Decentralized Cloud

Ali Mahdavi — Thu, 26 Mar 2026 17:28:17 +0000

Here is a quick guide on how to get a SvelteKit app live on a decentralized network in just a few minutes.

Why Use a Decentralized Network?

Cost Efficiency: You aren't paying for massive corporate overhead. For the same CPU and RAM, the cost is a fraction of what you’d pay on a standard PaaS.
Global Redundancy: Your app isn't tied to one data center. It is spawned across multiple independent nodes globally. If one node goes down, the network routing keeps your site live.
No Vendor Lock-in: It is built on open standards, meaning you own your deployment flow without being trapped in a specific ecosystem.

Step 1: Prepare your SvelteKit Project

Standard SvelteKit projects work perfectly. Just ensure your package.json includes the standard build and start scripts so the network knows how to handle the lifecycle:

"scripts": {
"build": "vite build",
"preview": "vite preview",
"start": "node build"
}

Note: If you are using SSR, make sure you are using @sveltejs/adapter-node or a compatible adapter.

Step 2: Configure the Deployment

The goal of "Deploy with Git" is to keep things simple. You don't need to manage complex server configurations. You just need to point the network to your repository.

I used this boilerplate guide:
github.com/RunOnFlux/deploy-with-git/tree/master/deploy-svelte

Step 3: Connect and Push

Go to the Flux Cloud Dashboard.
Select Deploy with Git.
Paste your GitHub/GitLab repository URL.
The network will automatically detect the environment, build your project, and distribute it across the global nodes.

Once it is live, every time you push to your main branch, the network detects the commit and updates your app automatically. If a build fails, it stays on the last working version so your users never see a 404.

Resources

Svelte Deployment Guide: github.com/RunOnFlux/deploy-with-git/tree/master/deploy-svelte
Official Documentation: docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/introduction

Let me know if you run into any issues setting this up!

Deploying a High-Availability NestJS API on Decentralized Infra

Ali Mahdavi — Thu, 26 Mar 2026 11:26:46 +0000

If you're running NestJS in production, you've likely faced the classic dilemma: go with the ease of a PaaS but pay the "convenience tax," or manage your own clusters to save money but lose hours to DevOps.

Lately, I’ve been experimenting with a third way: Decentralized Infrastructure.

I moved a NestJS microservice over to Flux Cloud using their Deploy with Git feature. It gives you the "push-to-deploy" workflow we love, but instead of hitting a single corporate data center, your API is distributed across multiple independent nodes globally.

Here is the technical breakdown of how to set this up and why the architecture is actually pretty clever for backend devs.

Why a Decentralized Backend?

Native High Availability: When you deploy on Flux, your app isn't on one server. It’s spawned across multiple separate, independent global nodes. If one provider goes offline, the network routing keeps your API reachable.
Predictable Scaling: Because it’s a peer-to-peer resource network, the costs for CPU and RAM are significantly lower and more stable than the "pay-as-you-go" surprises from the Big 3.
Zero-Downtime Rollbacks: The deployment engine handles the versioning. If a new push fails a health check, it automatically rolls back to the last stable version.

Step 1: Framework Preparation

NestJS works seamlessly here because it follows standard Node.js patterns. Ensure your package.json includes the production build and start scripts:

"scripts": {
"build": "nest build",
"start:prod": "node dist/main"
}

Step 2: Handling Environment & Ports

One thing to watch for is port assignment. NestJS usually defaults to 3000, but you should ensure your main.ts is flexible enough to pick up the environment port:

async function bootstrap() {
const app = await NestFactory.create(AppModule);
await app.listen(process.env.PORT || 3000);
}
bootstrap();

Step 3: Linking to the Network

Instead of writing complex configuration files from scratch, you can use the Git-deploy flow:

Connect your GitHub repository in the Flux dashboard.
The network automatically detects the NestJS environment.
It builds the project and propagates it to the nodes.

The Result: A "Self-Healing" API

What I like most about this setup is the resilience. In a traditional VPS setup, if the hardware fails, you're down until you manually intervene. Here, the network's "supervisor" keeps the app alive across the peer-to-peer nodes.

Useful Docs:

Technical Intro: docs.runonflux.com/fluxcloud/register-new-app/deploy-with-git/introduction
NestJS Example: github.com/RunOnFlux/deploy-with-git/tree/master/deploy-nestjs

How to Deploy Next.js to Flux Cloud: Decentralized, High-Uptime, and Budget-Friendly

Ali Mahdavi — Thu, 26 Mar 2026 08:10:25 +0000

If you are a Next.js developer, you are probably used to the "Vercel way" of doing things. It is great, but as projects grow, the costs can scale quickly, and you are tied into a single provider's ecosystem.

Flux Cloud recently released their new Deploy with Git feature. It is a decentralized alternative that offers a "push to deploy" experience but runs your app across a global network of independent nodes.

Here is why it is a solid choice for Next.js projects and how to get set up.

Why Next.js on Flux Cloud?

Drastically Lower Costs: Because Flux is a decentralized network, you aren't paying the "convenience tax" of major corporate clouds. It is often a fraction of the price for the same CPU and RAM.
Automatic Global Redundancy: Your Next.js app isn't just on one server. It is deployed across multiple nodes globally. If one node goes offline, the network keeps your site reachable.
Built-in Failover: If a deployment fails, Flux automatically rolls back to the last working version.
Full SSR Support: Unlike static-only hosts, Flux handles full-stack Next.js features, including Server-Side Rendering (SSR) and API routes, since it manages the runtime environment for you.

Step-by-Step Deployment

1. Prep your Repository

Flux makes it easy by detecting your framework. Ensure your package.json has the standard Next.js scripts:

"build": "next build"
"start": "next start"

2. Configure the Deployment

You can use the official Flux boilerplate to ensure your environment variables and ports are mapped correctly.

View the Next.js Deployment Guide here:
https://github.com/RunOnFlux/deploy-with-git/tree/master/deploy-nextjs

3. Connect to Flux Cloud

Go to the Flux Cloud Dashboard.
Select Deploy with Git.
Enter your GitHub/GitLab repo URL.
Flux will build your image and distribute it across the network.

4. Push to Update

Just like you are used to, any push to your main branch triggers a fresh build. Your global URL will update automatically once the new version is ready.

Useful Links

Next.js Deployment Example: GitHub Repo
Main Documentation: Flux Deploy with Git

Let me know if you try this out!

How to Deploy Vue.js to the Decentralized Flux Cloud (No more "Big Cloud" tax)

Ali Mahdavi — Thu, 26 Mar 2026 08:02:04 +0000

Most of us are used to the "standard" flow: push to GitHub, auto-deploy to a big-name provider, and hope the free tier doesn't vanish or the bill doesn't suddenly spike.

Flux Cloud is a decentralized computing network (thousands of independent nodes) which makes it significantly cheaper than the "Big 3" clouds. They just released a Deploy with Git feature that makes it as easy as any other PaaS.

Here is a quick guide on how to get a Vue app live on a decentralized network in a few minutes.

Step 1: Prepare your Vue project
You don't need to change much in your code. Just make sure your package.json has the standard scripts. Flux will look for these to build your project.

If you are using Vite (the Vue standard), ensure your build output is set to the default dist folder.

Step 2: The Flux Configuration
Flux uses a simple setup to understand how to run your app. You can find the boilerplate for this in the official Vue deployment guide here.

Essentially, you are just telling Flux:

Which branch to watch (e.g., main).
The build command (e.g., npm run build).
The port to serve it on.

Step 3: Connect and Deploy

Head over to the Flux Cloud Dashboard.
Select Deploy with Git.
Paste your GitHub repository URL.
Follow the wizard and deploy your app

Because it's decentralized, your app is "spawned" across the network. Once the build finishes, you'll get a global URL.

Step 4: Automatic Updates
The best part is that it stays synced. Whenever you push a change to your GitHub repo, Flux detects the commit, rebuilds the project, and updates the nodes. If a build ever fails, it automatically rolls back to the previous working version so your users never see a broken site.

Resources
Full Vue.js Guide: View on GitHub

Official Documentation: Flux Deploy with Git Intro