Skip to main content

Microfrontend quick start: from zero to rollback in 10 minutes

This is the golden path: the fewest steps that take you from nothing to a deployed microfrontend — and back, because a deploy you cannot undo is not one you should trust. It uses the free hosted console, so there is nothing to install.

Prefer your own infrastructure?

Everything below also works on a self-hosted installation. Run through it on the console first — it is the fastest way to judge whether the platform fits — and move to self-hosting when you need the bundles to stay in your network.

1. Create an account — no install​

Open console.flightroom.dev and register with email or Google SSO. You are then asked to create an organization — the tenant that owns your projects — and the project wizard opens inside it. That is the whole setup.

Details: Get started with Flightroom

2. Connect a repository and create a microfrontend​

  1. In Settings → Code Repositories, connect GitHub, GitLab or Azure DevOps.
  2. Back on the home page, choose Add New Microfrontend, pick a template, and give it a name and a slug.

The console creates the repository from the template, with the build pipeline already in it.

Details: Connect GitHub · Create a microfrontend

3. Publish a version​

On the microfrontend's card, choose Build, pick the branch and type a version — say 1.0.0. The console creates a Git tag with that name; your pipeline triggers on the tag, builds, and uploads the artifact. When it finishes, 1.0.0 appears in the version list.

Details: Versions and builds

4. Deploy​

Select version 1.0.0 on the microfrontend, then press Deploy on your environment. This captures an immutable snapshot — versions, variables, storage configuration — and activates it. Remember the platform's one rule: editing is not deploying. Nothing your users see changes until you press Deploy.

Details: Deployments overview

5. Integrate your host​

The console generates the Module Federation configuration (Vite or Webpack) your host application needs. It carries no URLs at all: each remote is declared as a slug handed to the client SDK, which resolves it at import time — the generated file even says so, "Never write a url here: the backend resolves the version". The two values it does embed are your project id and the backend URL, so the SDK knows which console to ask. Copy it once; from then on, releases never touch the host again.

Details: Integration overview

6. Roll back​

Publish and deploy a 1.0.1, then pretend it broke:

  1. Open Deployments → History for the environment.
  2. Expand the previous snapshot and check its versions.
  3. Press Redeploy.

The old snapshot is active again — no rebuild, no revert commit, no pipeline wait. This is the moment the platform earns its keep, and it took one click.

Details: Rollback and redeploy

Where to go next​

  • Core concepts — projects, environments, deployments and how they relate. Ten minutes that save you an hour later.
  • Environments and domains — one build serving DEV, UAT and PROD, resolved per request.
  • Runtime configuration — per-environment variables without a rebuild.
  • Self-hosting — Docker Compose, Docker or Terraform, with your own MongoDB and object storage.

If Flightroom is useful to you, a star on GitHub helps the project get found.