--- name: floci description: Run, wire up and troubleshoot Floci, the free local emulators for AWS (floci), GCP (floci-gcp), Azure (floci-az) and OCI (floci-oci), driven by floci-cli, docker run or Docker Compose. Use when the user wants to run cloud code or tests locally, mentions floci, localhost:4566/4577/4588/4599, a LocalStack or Azurite alternative, local S3/DynamoDB/Pub/Sub/Blob/Object Storage, asks for a docker-compose.yml or compose.yaml with a cloud emulator, emulator namespaces, or several emulator instances side by side. --- # Floci Floci is a family of local cloud emulators that speak the real cloud wire protocols. The `floci` command (floci-cli) manages their lifecycle; the native tools (`aws`, `gcloud`, `az`, `oci`, SDKs, Terraform) do the resource work against the emulator. floci-cli never creates cloud resources itself. | Cloud | Emulator | CLI tree | Port | Default container | Reference | |-------|----------|----------|:----:|-------------------|-----------| | AWS | floci | `floci aws` | 4566 | `floci` | [references/aws.md](references/aws.md) | | GCP | floci-gcp | `floci gcp` | 4588 | `floci-gcp` | [references/gcp.md](references/gcp.md) | | Azure | floci-az | `floci az` | 4577 | `floci-az` | [references/azure.md](references/azure.md) | | OCI | floci-oci | `floci oci` | 4599 | `floci-oci` | [references/oci.md](references/oci.md) | All paths in this skill (`references/`, `scripts/`, `assets/`) are relative to the directory that holds this file, not to the user's working directory. When to read what: - The cloud's reference, before the first resource command for that cloud. - [references/docs.md](references/docs.md), before writing code against a service you have not used in this session, and whenever an operation looks unsupported. It tells you how to fetch the right page of the published documentation. - [references/docker.md](references/docker.md), when the user wants `docker run`, a `docker-compose.yml`, or an app container that talks to the emulator. - [references/namespaces.md](references/namespaces.md), when running more than one instance, sharing a Docker host, or cleaning up containers. - [references/ci.md](references/ci.md) for pipelines and Testcontainers. - [references/troubleshooting.md](references/troubleshooting.md) when anything fails. ## Prerequisites (check first) ```sh command -v floci && floci version # floci-cli present? docker info >/dev/null && echo ok # Docker (or Podman via DOCKER_HOST) reachable? ``` If `floci` is missing, **ask the user before installing software**, then run: ```sh scripts/install-floci.sh # brew if available, else official script into ~/.local/bin scripts/install-floci.sh --version 0.4.0 # pin a version (uses the install script) ``` - Windows: `iwr https://floci.io/install.ps1 | iex` (per-user, no admin). The helper scripts here are bash; on Windows run the `floci` commands they wrap directly. - No native binary for the platform: download `floci.jar` from the latest release and run `java -jar floci.jar` (needs Java 25+). - Do not use `sudo` or edit shell profiles (`~/.bashrc`, `~/.zshrc`) without asking; if the install dir is not on `PATH`, export it for the current session only. - Updates: `floci update --check` exits 0 when up to date, 1 when an update exists and 2 when the check itself failed. Run `floci update` only on exit 1 (Homebrew installs: `brew upgrade floci`). - The user does not want the CLI at all: the emulators are plain container images, see [references/docker.md](references/docker.md). floci-cli does not install Docker. If the daemon is missing, tell the user; do not install Docker yourself. The native cloud CLIs (`aws`, `gcloud`, `az`, `oci`) are only needed for the clouds the user works with; suggest installing them, do not install them unasked. ## Hard rules 1. **Never touch real cloud.** Use only the fake credentials the emulators accept (`test`/`test` for AWS, the dev identities `floci az setup` and `floci oci setup` create). Never read, export or reuse the user's real cloud credentials or profiles. 2. **Verify the endpoint before every mutating command.** It must point at the emulator (`localhost`, `127.0.0.1`, `localhost.floci.io`, or a Compose service name). If a command might reach public cloud (see each reference's "leaks" section), stop and fix the wiring. 3. **Always name the tree explicitly**: `floci aws start`, not `floci start`. Bare commands follow `floci config default-product`, which the user may have changed. 4. **Parse with `-o json`**, never scrape text output. Use `-q` to silence noise in scripts. 5. **Do not remove containers, volumes or snapshots you did not create** in this session. Scope any cleanup to a namespace (see namespaces.md) and confirm with the user first. 6. **State is ephemeral** unless the instance was started with `--persist ` or a profile with `persistDir`. Both `start` on a stopped container and `restart` remove the container and create a new one: `restart` keeps the settings (port, image, services, persist dir, namespace) but not in-memory state, and on Azure the new container has a new certificate, so `floci az setup` must be run again. `start` on a running container fails. Say so before recreating anything. 7. **Never add `-q` to `env`**: it suppresses the exports themselves. 8. **Do not guess what an emulator supports.** Check `floci services -o json` and the published docs ([references/docs.md](references/docs.md)) instead of answering from memory. 9. **With a profile, start and wait before `env`.** Until the profile's container is running, `env` and `status` fall back to the default port and describe the default instance. Trust `"state": "running"` in `status -o json`, not `reachable`. ## Lifecycle (same for every tree) ```sh floci start --detach # pull if needed, start, return immediately floci wait --timeout 2m # block until healthy (exit 0 = ready) eval "$(floci env -o text)" # export SDK/CLI wiring into this shell # ... run aws / gcloud / az / oci / tests ... floci stop --remove # when done, only if you started it ``` `-o text` keeps the exports correct even when a profile sets `output: json`. In other shells: `floci env --shell fish | source`, or `floci env --shell powershell | Invoke-Expression`. Or use the helper, which starts the container only when none exists, then waits and prints the exports: ```sh exports="$(scripts/ensure-running.sh [profile])" && eval "$exports" ``` Keep the two steps: `eval "$(...)"` in one go succeeds even when the helper fails, and the commands after it would run with missing or stale wiring. The helper exits 3 without touching anything when the container exists but is stopped, because starting it replaces it (rule 6). Tell the user, and re-run with `FLOCI_REPLACE_STOPPED=1` once they agree. One-time per instance, before using the native CLI: - Azure: `floci az setup` (trusts the emulator cert, registers an az cloud, logs in). - OCI: `floci oci setup` (writes a throwaway key and a `[FLOCI]` profile in `~/.oci/config`). `eval` only affects the current shell. If each tool call runs in a fresh shell, prefix every command: `eval "$(floci aws env -o text)" && aws s3 ls`. The examples are written for bash. In zsh (the macOS default) an unquoted variable is not split into words, so `flags="--profile aws-b"; floci aws status $flags` passes one argument and fails. Write the flags out, or use an array: `flags=(--profile aws-b)` and `"${flags[@]}"`. ## Inspecting state | Need | Command | |------|---------| | Is it running and healthy? | `floci status -o json` | | Which services are enabled? | `floci services -o json` (Azure: returns an empty list, see azure.md) | | CLI and server versions | `floci version -o json` (Azure: read the version from `status -o json`) | | Recent server logs | `floci logs --tail 100` or `--since 5m` | | Environment problems | `floci doctor -o json` (an array of checks with `status` `ok`, `warn` or `fail`; see troubleshooting.md before acting on a `fix`) | | Effective config | `floci config show --profile ` (the namespace row appears only with a profile that yields one) | | All instances | `floci config profile list -o json` (profiles are shared by all trees; `image` tells the cloud). Also `config profile show`, `edit` and `delete ` | | Any command's flags | `floci --help` | ## Several instances An instance is a profile: its container name is its identity, its port must be unique, and its Docker resource namespace keeps the containers it launches apart from other instances. Pass the same `--profile ` to every command for that instance. Details and the namespace derivation rules are in [references/namespaces.md](references/namespaces.md). ```sh floci aws config profile create aws-b --container floci-b --port 14566 --persist ~/.floci/data/aws-b floci aws start --profile aws-b # waits up to 30s; or --detach, then wait eval "$(floci aws env -o text --profile aws-b)" ``` floci-cli keeps its own files under `~/.floci` (profiles in `~/.floci/profiles/`, per-instance state in `~/.floci///`), so instance data goes there too, as `~/.floci/data/`. ## Choosing the right integration - **Ad-hoc commands or a dev server**: the CLI lifecycle above. - **The user asks for `docker run` or a Compose file, or the app itself runs in a container**: [references/docker.md](references/docker.md). Start from the templates in `assets/compose/` instead of writing YAML from memory. - **Integration tests in code**: a Testcontainers module where one exists (AWS in Java, Node, Python, Go and .NET; Azure in Java only; none for GCP or OCI, see ci.md). Otherwise start the emulator with the CLI or Compose before the tests. ## When something is not supported Coverage differs per service: some are full engines, some are in-process, some answer with canned responses. Before writing code against a service, check that it is enabled (`floci services -o json`) and read its page in the published docs ([references/docs.md](references/docs.md)). If an operation is missing, say so plainly, suggest a workaround, and point the user to the emulator's issue tracker (`https://github.com/floci-io//issues`) instead of retrying variations.