Overview

The Static Web Apps module allows project administrators to publish prebuilt frontend applications in Alluvial.

These apps are intended for static, client-side experiences such as React, Vue, Angular, documentation sites, dashboards, and other browser-based tools that can be delivered as HTML, CSS, JavaScript, fonts, images, and media files.

Unlike Containerized Apps, Static Web Apps do not run a server-side runtime in Alluvial. Instead, Alluvial stores the uploaded package in private Azure Blob Storage, deploys the extracted files, and opens the application inside the Alluvial experience.

IMPORTANT: The module only appears when it has been enabled for the project and the user has the appropriate permission to manage Static Web Apps. If it is missing, ask a project owner or project administrator to review your access in User Administration.

Getting Started

Access Static Web Apps

  1. Navigate to the Administration page in your Alluvial project.
  2. Select Static Web Apps to open the project's static app management view.

Core Concepts

What Is a Static Web App in Alluvial?

A Static Web App in Alluvial is a packaged frontend build that is deployed as files rather than as a running container.

Typical examples include:

  • React or Vue single-page applications
  • static documentation sites
  • map viewers or dashboards that call APIs directly from the browser
  • lightweight internal tools that do not require a platform-hosted server runtime

Private Blob-Backed Hosting

Uploaded packages are stored in private Azure Blob Storage managed by Alluvial.

During deployment, Alluvial validates the uploaded archive, extracts the supported files, applies content types and cache rules, and marks the app as ready when deployment completes successfully.

Project App vs. App Host

The project-facing Static Web App entry controls the display name, child domain, and project-specific navigation and access settings.

Behind the scenes, the deployed package is managed as a hostable static app bundle. In some organizations, Alluvial Platform Administrators may also manage reusable static app hosts that can later be connected to one or more projects.

Package Requirements

Your uploaded archive should:

  • contain an index.html file at the root of the packaged app, or inside a single top-level build folder
  • include only client-side web assets such as HTML, CSS, JavaScript, JSON, images, fonts, and media
  • be a prebuilt output package, not raw source code that still needs a build step inside Alluvial

If your application depends on a server process, background worker, or runtime framework that must execute on the platform, use Containerized Apps instead.

Status Lifecycle

Static Web Apps move through a deployment lifecycle:

  • Draft - the entry exists, but no deployed package is ready yet
  • Processing - Alluvial is validating and deploying the uploaded package
  • Ready - the deployed files are available to users
  • Failed - the deployment did not complete successfully; review the failure reason on the form

Child Domain Name

The Child Domain Name identifies the app at its generated application URL. Choose it carefully and keep it short, lowercase, and unique within your Alluvial environment.

Plan this value early. In many workflows, the child domain is easiest to finalize before the app leaves draft status.

Access Control

End users still need access to the project, and you can further restrict a Static Web App through Custom Roles.

This makes it possible to publish a static app into a project without exposing it to every project user.

Common Tasks

Create a New Static Web App

  1. Open Static Web Apps.
  2. Click CREATE NEW.
  3. Complete the form.
  • Name - Display name shown in Alluvial
  • Child Domain Name - Unique subdomain used for the app URL
  • Description - Optional explanation of the app
  • Application Package - Compressed archive containing your built frontend application
  1. Upload your application package.
  2. Save the form.

When saved with a new package, the app enters Processing while Alluvial validates and deploys the files.

Prepare the Application Package

Before uploading:

  • build the app outside Alluvial using your normal toolchain
  • package the deployed output, not the full source repository
  • confirm that index.html is present at the root of the deployed app structure
  • ensure asset paths are compatible with the generated build output

If your framework produces a dist, build, or similar output folder, package that output rather than your development source files.

Monitor Deployment

After saving:

  1. Reopen or refresh the entry.
  2. Watch the Status field.
  3. If deployment fails, review the Failure Reason field.
  4. Upload a new package and save again to redeploy.

When the status becomes Ready, the application can be exposed through menu links, default page settings, or dashboard tiles, depending on how the rest of the form is configured.

Configure Navigation and Visibility

Use the remainder of the form to integrate the app into the project experience.

Common follow-up configuration includes:

Update an Existing Static Web App

  1. Open the existing entry.
  2. Update the descriptive fields or project navigation settings as needed.
  3. Upload a new application package if you need to redeploy updated frontend files.
  4. Save the form and allow the app to return to Ready.

Choose Static Web Apps vs. Containerized Apps

Use Static Web Apps when:

  • the application is a browser-based frontend build
  • no platform-hosted server process is required
  • the application can be delivered entirely as static files

Use Containerized Apps when:

  • the application needs a server runtime
  • backend code must run inside Alluvial
  • startup scripts, background workers, or runtime-managed dependencies are required