Hysen Labs
Open-source project
floci-io/floci-ui avatar
floci-io

floci-ui

Any Cloud. Locally. - The local cloud console for Floci, an AWS-Console-style UI for your local multi-cloud runtime.

297 stars85 forksTypeScriptMIT
DEEP OPEN-SOURCE ANALYSIS

Floci UI is a local cloud console for multi-cloud runtimes

Floci UI is a web console that presents a unified Cloud Explorer and Console Home for local multi cloud runtimes, rendering only real data returned by those runtimes.

What the console shows

Floci UI is the web console for the Floci ecosystem, described as a local first, cloud aware runtime console. The current app centers on a unified Cloud Explorer and a cloud aware Console Home. The README is explicit that the interface renders only real data returned by local runtimes and explicit placeholders for work that is not wired yet, with no fake resources, no demo rows, and no mock operational data in normal mode. That honesty about coverage is unusual for a console demo and is a deliberate design choice. The sidebar and Console Home are rendered from a service catalog endpoint, GET /api/clouds/:cloud/services, so the visible feature matrix is derived from the service catalog and the adapter registry rather than maintained by hand. A script, bun run scripts/service-matrix.ts in the api package, regenerates the matrix after any change to either source. The README includes a table showing which services work per cloud. Compute listing, inspecting, creating, and deleting is available for AWS and Azure, while GKE works on GCP. Storage operations are present across all three clouds. Some services are marked No and render as disabled sidebar rows whose tooltip carries the server supplied reason. This means the UI is a faithful view of what the backing runtime actually implements, and a missing feature is shown as missing rather than faked.

Service coverage and gaps

The service matrix in the README lays out what each cloud adapter currently exposes through the console. Compute is listed, inspected, created, and deleted for AWS and Azure, and GKE supports list, create, inspect, and delete on GCP while EKS and AKS support list and inspect. Serverless works for AWS and GCP with list, create, inspect, and delete, but Azure shows a runtime gap. Storage covers list, create, delete, and inspect on all three providers. Databases are listed and inspected on AWS, with create and delete on Azure and GCP, and DynamoDB or Cosmos NoSQL coverage exists for AWS. Networking is list only on AWS, API Gateway list, create, delete, and inspect on AWS, and CloudFormation infrastructure as code on AWS. Secrets Manager and Key Vault work on AWS and Azure respectively. Console Home is available for all three clouds. The README names one concrete runtime gap: the Floci-AZ runtime returns 501 NotImplemented for the Azure Functions endpoint, so Azure Serverless appears but cannot be invoked. Services marked No render as disabled rows with a tooltip explaining why. Adding a new service is described as adding a catalog row in serviceCatalog.ts plus an adapter, with no frontend change required, because the UI reads its shape from the catalog. That architecture keeps the console honest about what the local runtime can actually do.

Running it locally

The quick start uses Docker Compose. An AWS only stack comes up with docker compose up, while the full multi cloud stack uses docker compose with the multicloud profile, docker compose --profile multicloud up. After the containers start, the console is served at http://localhost:4500. The README badges confirm a latest release, a CI workflow, Docker pulls, and image size, all pointing at the floci-io organization. The project also links a Docker Hub image at floci/floci-ui. Because the console only renders data from local runtimes, the experience depends on what those runtimes implement; the UI will not invent resources to look complete. The documentation screenshots show the console window and a service matrix, and the repo structure splits the api package from the frontend. Regenerating the service matrix after catalog changes is a one line bun script, which keeps the displayed table in step with the adapter registry. The architecture decision to derive the sidebar from a service catalog means new cloud support is mostly a backend concern. A developer adding GCP or Azure coverage writes an adapter and a catalog entry, and the frontend picks it up. The local first framing also means no data leaves the machine to a vendor console, which is the point of the Any Cloud, Locally tagline repeated in the README.

Editorial conclusion

The project is published under the MIT license and written in TypeScript, with its source at the floci-io floci-ui repository.

DEEP OPEN-SOURCE ANALYSIS

Official sources

Community notes

Community notes