Labs64.IO :: Workspace
Work on the whole Labs64.IO Ecosystem from source, in one command.
Part of the Labs64.IO Ecosystem: the contributor entry point: every repository, one toolchain, one local platform.
Get started · Features · AI agents · Ecosystem · Documentation · labs64.io
[!NOTE]
Labs64.IO is ten independent Git repositories, not a monorepo. If you only want to see it running you do not need the workspace: use install.sh.
Why Workspace?
Changing a platform that spans many repositories means the same toolchain, the same pinned versions and a local cluster that behaves like the real thing. Setting that up by hand is a day you do not get back; Workspace makes it a command.
- One checkout command.
just clone fetches every ecosystem repository next to the workspace.
- One pinned toolchain. A dev container carries every tool at the version the repositories expect.
- One local platform.
just up builds every first-party image and deploys it to a k3d cluster; just smoke checks it.
A good fit if
- You are about to change code in one or more Labs64.IO repositories and want a working environment fast.
- You review pull requests that span repositories.
- You want an AI agent to work across the ecosystem with the same tools you have.
Probably not what you need if
- You only want to see Labs64.IO running:
install.sh is quicker and needs no checkouts.
- You are using one module in your own project: use that module's Docker or Kubernetes option instead.
Features
- Multi-repo bootstrap:
just clone fetches every ecosystem repository next to the workspace.
- Pinned dev container: every tool at the version the repositories expect, with Docker-outside-of-Docker.
- Local platform:
just up builds first-party images in a builder container and deploys them to k3d with a local registry.
- Smoke tests:
just smoke checks the running platform through the gateway.
- Knowledge graph and AI skills: a graph of the ecosystem and skills for agents working across repositories.
- Version and release tooling: pin checks, release and dependency-update recipes.
The DevContainer mounts labs64-m2-cache at /home/vscode/.m2, so direct
mvn commands and the shared container builder install and resolve artifacts from
the same local Maven repository regardless of which module starts the build.
Is this the right place to start?
| You want to… | Start here |
|---|
| See Labs64.IO running and call an API | You do not need this workspace: the Quickstart installs published images in about five minutes |
| Try one service without Kubernetes | Run one module locally |
| Deploy for your team on AWS, Azure, Google Cloud or your own cluster | Deploy to your Kubernetes cluster |
| Change the code, build from source, contribute | You are in the right place |
Using it with AI agents
Agents get the same environment a human contributor does, with one just entry point and a knowledge graph for following changes across repositories. The guide for AI agents covers authentication, retries and errors across all modules. Working on this repository with an agent? AGENTS.md and CLAUDE.md describe the layout and conventions.
The Labs64.IO Ecosystem
Workspace is one module of the Labs64.IO Ecosystem; every module is documented here.
Contributing
We would love your help. The workspace is where contributors spend their first hour, so every rough edge you smooth here helps the next person. Fork the repository, make your change on a branch, run the checks described in AGENTS.md and open a pull request. Not sure whether an idea fits? Open an issue first and we will talk it through; that is a perfectly good way to start.
License
Everything in this repository is open source under the Apache License 2.0: you can use it, change it and ship it commercially. The core of the Labs64.IO Ecosystem is free forever; community modules are Apache-2.0 licensed.
