# Floci UI: an AWS-style console for your local cloud emulators

> Floci UI is the web console for the Floci ecosystem, rendering real data from local AWS, Azure and GCP emulators instead of mock rows. It is early, uneven across providers, and honest about what is not wired yet.

**floci-io/floci-ui** — Any Cloud. Locally. - The local cloud console for Floci, an AWS-Console-style UI for your local multi-cloud runtime.

- Repository: https://github.com/floci-io/floci-ui
- Website: https://floci.io
- Stars: 415 · Forks: 123
- Language: TypeScript
- License: MIT
- Published: 2026-08-27 · Updated: 2026-08-27 · Language: en
- Canonical page: https://hysenlabs.com/projects/floci-io-floci-ui

## What Floci UI is for, and who it is for

Floci UI is the web console for the Floci ecosystem. Its README describes it as "a local-first, cloud-aware runtime console for Floci and compatible local cloud emulators", centred on a unified Cloud Explorer and a cloud-aware Console Home. The stated design rule is narrow and worth repeating: it renders only real data returned by local runtimes, plus explicit placeholders for work that is not wired yet. No fake resources, no demo rows, no mock operational data in normal mode.

That rule is the whole pitch. If you run Floci locally to stand in for AWS, Azure or GCP, you normally inspect the result through a CLI or raw HTTP calls. Floci UI gives you a console-shaped view of the same data. It is aimed at developers working on a local stack, not at anyone operating real cloud accounts. The repository is TypeScript, MIT licensed, and the last push was on 2026-08-18, which is the 0.3.0 release date.

## How the Cloud Explorer decides what to show

The sidebar and Console Home are rendered from GET /api/clouds/:cloud/services. The README states that the capability table is derived from the service catalog and the adapter registry rather than maintained by hand, and gives a regeneration command for it. That means the UI is not a hand-written set of pages per provider. A cloud is a catalog entry plus an adapter, and the frontend reads the resulting service list.

The practical consequence is visible in the interface. Services marked No render as a disabled sidebar row whose tooltip carries the server-supplied reason. The README gives the Azure example directly: Serverless reads "coming soon" because the Floci-AZ runtime answers 501 for the Azure Functions endpoint, even though an adapter is registered. That is a runtime gap rather than a UI gap, and the console surfaces the distinction instead of hiding it.

The README also states that adding a service is a catalog row in packages/api/src/cloud-spi/serviceCatalog.ts plus an adapter, with no frontend change. Treat that as an architectural claim from the documentation, not a measured one. It does explain why coverage differs so sharply between providers: the console can only show what adapters and runtimes exist.

## Installing Floci UI and opening the console

The README's Quick Start is two commands. The AWS-only stack comes up with docker compose up, and the full multi-cloud stack with docker compose --profile multicloud up. The Makefile wraps the same thing: make up and make up-multicloud, both passing -d, with make down tearing down the multicloud profile.

```bash
docker compose up
```

After that, open http://localhost:4500. The compose file maps port 4500 for the floci-ui service and 4501 for floci-api, and the frontend container is given API_TARGET: http://floci-api:4501.

The api service is configured through environment variables, and .env.example lists the same keys for a non-Docker run: FLOCI_ENDPOINT, FLOCI_AZURE_ENDPOINT, FLOCI_GCP_ENDPOINT, FLOCI_GCP_PROJECT, AWS_REGION, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and PORT. In compose, FLOCI_ENDPOINT points at http://floci:4566, the Azure endpoint at http://floci-az:4577, and the GCP endpoint at http://floci-gcp:4588 with FLOCI_GCP_PROJECT set to floci-local. The credentials are literally test/test, which tells you what this stack is for.

```yaml
environment:
  FLOCI_ENDPOINT: http://floci:4566
  FLOCI_AZURE_ENDPOINT: http://floci-az:4577
  AWS_REGION: us-east-1
  AWS_ACCESS_KEY_ID: test
  AWS_SECRET_ACCESS_KEY: test
  FLOCI_GCP_ENDPOINT: http://floci-gcp:4588
  FLOCI_GCP_PROJECT: floci-local
  PORT: "4501"
```

One detail deserves attention before you run it. The compose file mounts /var/run/docker.sock into the floci service, with a comment explaining that Floci runs Lambda functions in throwaway containers and fails to start them without host Docker access. The comment calls this acceptable for a local dev stack. It also means the emulator has control of your Docker daemon. Run this on a machine you are willing to expose that way.

For source work, the root package.json defines dev, dev:web, dev:api, build, lint, type-check and test scripts, and pins packageManager to pnpm@9.2.0. The Makefile's install target is less tidy: it runs npm install in packages/frontend and ~/.bun/bin/bun install in packages/api, hardcoding a Bun path.

## Coverage is uneven, and the gaps are documented

The capability table is the most useful page in the README, because it tells you where Floci UI is a real tool and where it is a shell. Storage is the most complete unified category: AWS S3 buckets, Azure Blob containers and GCP Cloud Storage buckets are all normalized into storage resources, with a shared resource table, shared inspector, runtime status strip, and schema-driven create and delete flows. There is an object browser with prefix navigation, upload, download, delete, copy, and create-folder-prefix actions.

Compute is where the multi-cloud story thins out. The table lists Compute as Yes for AWS and Azure and No for GCP. The detailed section then says Compute is "AWS only, through the unified shell plus AWS-specific panels where the workflow is too rich for a flat generic form", with EC2 list, launch, start, stop, reboot, terminate, AMI creation, tag editing and console output. Azure VMs are listed as a capability in the matrix but as a missing adapter in the prose. That contradiction is in the source documentation and I cannot resolve it from here; verify against your own build before assuming either way.

Other categories are narrower still. Networking is AWS only, with VPC list and inspect through the unified table and create/delete handled by an AWS-specific panel because they need dependent selectors a flat generic form cannot express. The README marks those operations as "partial" in the unified schema. API Gateway covers AWS only, and its own gaps list says resources, methods, deployments and stages are not exposed. Database is the messiest: AWS RDS is list and inspect oriented, Azure Cosmos DB NoSQL has full database, container and document workflows plus a SQL query editor, and the README states there is no unified cross-provider database contract beyond the shared category shell. DynamoDB has not been rebuilt into the new Cloud Explorer model.

## Where Floci UI is the wrong tool

The console is only as good as the runtime behind it, and the README is explicit that some endpoints are not implemented. Azure Serverless is the named example: the Floci-AZ runtime returns 501 NotImplemented for the Azure Functions endpoint. If your work depends on Azure Functions locally, this console will show you a disabled row, not a function list.

The second limit is the shape of the workflows. Compute creation still uses an AWS-specific panel because it needs dependent selectors. Networking create and delete are marked partial in the unified schema for the same reason. The unified shell only stretches so far, and the project has chosen to keep provider-specific panels rather than force everything through one generic form. That is a reasonable call, but it means the "unified" promise holds unevenly across categories.

The third limit is operational. Storage has no bulk multi-select actions, no tag, policy or version management in the unified view, and folder creation is prefix-based rather than a real filesystem directory. If you need lifecycle rules or object versioning to reason about a bucket, the console will not show them. And if you are looking for anything resembling a production cloud management plane, this is not it: the credentials in the compose file are test/test, and the whole stack is built to talk to emulators on a loopback network.

## How this differs from LocalStack's own tooling

The obvious comparison is LocalStack, which also emulates AWS locally and ships a web interface for inspecting resources. The difference is scope and provenance. LocalStack is an AWS emulator with its own console. Floci UI is a console for the Floci emulators, and its architecture assumes more than one cloud: the service catalog and adapter registry exist so that AWS, Azure and GCP can be presented through the same navigation, with per-provider labels. The README notes that on the same build the nav is grouped by category and the k8s Engine entry is labelled AKS for Azure.

That multi-cloud framing is also the source of the weakness. A single-provider emulator console does not have to reconcile three resource models. Floci UI does, and the README admits the reconciliation is incomplete: no unified cross-provider database contract, no advanced multi-cloud networking normalization, and AWS carrying most of the working surface. If your local work is AWS-only, that extra layer buys you little. If your local work spans providers and you accept the uneven coverage, the shared shell is the reason to pick this over a single-cloud console.

## Maintenance cost, release cadence and licence

The release history is short and recent: 0.1.0 on 2026-06-15, 0.2.0 on 2026-07-09, and 0.3.0 on 2026-08-18, which is also the date of the last push. The root package.json carries version 0.4.0, ahead of the newest listed release, so the repository and the tag history are not perfectly in step. Three releases in two months is a fast cadence for a project at this stage, and it also means the surface you adopt now will move.

Upgrade cost is tied to the architecture. Because the capability table is generated from the service catalog and adapters, and the README says adding a service is a catalog row plus an adapter with no frontend change, the console is designed so that provider coverage grows without rewriting the UI. The flip side is that adapter and catalog changes are where breakage will concentrate, and the README's own instruction is to regenerate the matrix after any change to either. The regeneration command is cd packages/api && bun run scripts/service-matrix.ts.

The project is MIT licensed, which is permissive and places few obligations on how you reuse or redistribute it. That is a statement about the licence text, not advice about your situation; if you plan to ship it inside a product, read the LICENSE file yourself. One thing the documentation does not cover is rollback or downgrade procedure between releases, so it is silent on how to return to an earlier version if an upgrade misbehaves.

## Conclusion

Adopt Floci UI if you already run Floci emulators locally and want a console that reflects what those runtimes actually return, and if you can live with AWS carrying most of the surface area. Do not adopt it if you need a stable cross-provider contract for databases or networking, or if you expect Azure and GCP parity. Before committing, run the AWS-only stack with docker compose up, open http://localhost:4500, and check the service matrix for the exact provider and service you depend on, because the table is generated from the catalog and adapter registry rather than maintained by hand.

## FAQ

### What is Floci UI?

It is the web console for the Floci ecosystem, described in its README as a local-first, cloud-aware runtime console for Floci and compatible local cloud emulators. It centres on a unified Cloud Explorer and a cloud-aware Console Home, and renders only real data returned by local runtimes plus explicit placeholders for unfinished work.

### Is Floci UI a good alternative to LocalStack's console?

The two are not the same shape: LocalStack is an AWS emulator with its own console, while Floci UI is a console for the Floci emulators and assumes multiple clouds through a service catalog and adapter registry. The README states that cross-provider coverage is incomplete, with no unified database contract and AWS carrying most of the working surface, so the multi-cloud shell only pays off if you actually run more than one provider locally.

### How do I run Floci UI with Docker?

The README's Quick Start uses docker compose up for the AWS-only stack and docker compose --profile multicloud up for the full multi-cloud stack, then you open http://localhost:4500. The Makefile offers the same as make up and make up-multicloud.

## Sources

- [Official documentation](https://floci.io)
- [Official README](https://github.com/floci-io/floci-ui#readme)
- [Project repository](https://github.com/floci-io/floci-ui)
- [Release notes](https://github.com/floci-io/floci-ui/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/floci-io-floci-ui