https://github.com/codeforester/banyanlabs
A hands-on platform engineering and SRE lab for building real services, CI/CD, observability, Kubernetes, infrastructure as code, and multi-cloud operations from a local-first foundation.
https://github.com/codeforester/banyanlabs
Last synced: 10 days ago
JSON representation
A hands-on platform engineering and SRE lab for building real services, CI/CD, observability, Kubernetes, infrastructure as code, and multi-cloud operations from a local-first foundation.
- Host: GitHub
- URL: https://github.com/codeforester/banyanlabs
- Owner: codeforester
- License: mit
- Created: 2026-04-09T06:00:21.000Z (2 months ago)
- Default Branch: main
- Last Pushed: 2026-06-05T14:40:26.000Z (15 days ago)
- Last Synced: 2026-06-05T16:08:31.209Z (15 days ago)
- Language: Go
- Size: 117 KB
- Stars: 1
- Watchers: 0
- Forks: 0
- Open Issues: 12
-
Metadata Files:
- Readme: README.md
- Changelog: CHANGELOG.md
- Contributing: CONTRIBUTING.md
- License: LICENSE
- Codeowners: .github/CODEOWNERS
Awesome Lists containing this project
README
# Banyan Labs
Banyan Labs is a realistic infrastructure and platform engineering lab.
The purpose is to build deep DevOps, SRE, and platform engineering knowledge by
assembling real services and infrastructure tools into a meaningful environment.
Certifications can introduce AWS, GCP, Azure, Kubernetes, Terraform, CI/CD,
monitoring, and distributed systems, but Banyan Labs is about learning those
ingredients by building with them.
The long-term goal is to grow toward the complexity of a medium-sized
engineering organization: multiple services, multiple languages, local and
remote environments, CI/CD, infrastructure as code, observability, Kubernetes,
and eventually multi-cloud patterns based on real open source tools.
The first concrete service is a Go URL shortener with local SQLite storage,
authentication, user management, tests, and a minimal HTML UI from day one.
See [Banyan Labs Vision](docs/banyanlabs-vision.md) for the broader direction.
See [Platform Roadmap](docs/platform-roadmap.md) for the phased path from the
local service to observability, delivery, Kubernetes, infrastructure as code,
and cloud environments.
## Local Setup
Banyan Labs uses Base for workspace orchestration and `mise` for language
runtime versions.
From the repository root:
```bash
basectl setup banyanlabs
```
That setup path uses:
- `Brewfile` to install `mise` and API test tooling
- `.mise.toml` to install the Go runtime
- `base_manifest.yaml` to connect those tools to Base
After setup:
```bash
basectl test banyanlabs
basectl run banyanlabs api-test
basectl run banyanlabs build
basectl run banyanlabs dev
```
API contracts and black-box smoke tests live with the repo:
- `services/url-shortener/openapi.yaml`
- `tests/api/url-shortener/*.hurl`
## Relationship to Base
The shared developer bootstrap layer no longer lives here.
That foundational layer now belongs in
[`base`](https://github.com/codeforester/base#readme), including:
- shell environment bootstrap
- shared Bash wrapper and command conventions
- common shell libraries
- workspace-level setup and test entrypoints
The intended local workspace shape is:
```text
work/
base/
banyanlabs/
other-project/
```
In that model:
- `base` owns shared developer tooling and workspace orchestration
- `banyanlabs` owns Banyan Labs-specific code, manifests, infrastructure, and
project behavior
## What This Repo Will Focus On
Banyan Labs focuses on project-level and product-level concerns such as:
- project source code
- infrastructure definitions
- service code
- manifests and configuration specific to Banyan Labs
- project-specific documentation
- project-specific tests and automation
## Status
This repo is being rebuilt around a local-first platform lab.
The shared CLI/bootstrap artifacts moved into the sibling `base` repo. Banyan
Labs now owns the services, docs, tests, and project-specific infrastructure
that will grow on top of that workspace model.
## Development Workflow
Banyan Labs follows Base's issue-first GitHub workflow:
- track work in GitHub Issues before implementation starts
- prefer `basectl gh` for supported GitHub issue and pull request tasks
- use one worktree per pull request
- keep each PR scoped to one issue and link it with `Fixes #`
See [CONTRIBUTING.md](CONTRIBUTING.md) and
[docs/github-workflow.md](docs/github-workflow.md) for the full workflow.