A comprehensive AI development platform for Kubernetes that provides GPU resource management, containerized development environments, and workflow orchestration.
Documentation · Helm Chart · Backend · Frontend
 Jupyter Lab |
 Ray Job |
 Monitor |
 Models |
Crater is a Kubernetes-based platform that helps teams manage heterogeneous compute resources (e.g., GPUs) and run AI workloads through unified scheduling, development environments, and observability.
- 🎛️ Intuitive UI: Manage clusters, jobs, and resources through a clean web interface.
- ⚙️ Intelligent scheduling: Allocate resources based on priority and requirements to improve utilization.
- 📈 Monitoring & logs: Observe cluster status and troubleshoot with metrics and logs.
High-level architecture of Crater and its major components.
- Admin guide (中文): https://raids-lab.github.io/crater/zh/docs/admin/
- Admin guide (English): https://raids-lab.github.io/crater/en/docs/admin/
Deployment guides:
If you want to quickly deploy a basic Crater using Kind, please refer to Minimal Deployment.
If you want to deploy a full Crater in a cluster, please refer to Cluster Deployment Guide.
English versions:
- A running Kubernetes cluster
kubectl- Helm v3
To get started with Crater, you first need to have a running Kubernetes cluster. You can set up a cluster using one of the following methods:
Kind (Kubernetes IN Docker) is a lightweight tool for running local Kubernetes clusters using Docker containers.
Minikube runs a single-node Kubernetes cluster locally, ideal for development and testing.
📖 https://minikube.sigs.k8s.io/
For deploying Crater in a production or large-scale test environment, you can use any standard Kubernetes setup.
📖 https://kubernetes.io/docs/setup/
Use the docs above for a full guide. The chart version can be found in
charts/crater/Chart.yaml(fieldversion) or GitHub releases.
helm registry login ghcr.io
helm install crater oci://ghcr.io/raids-lab/crater --version <chart-version>backend/: Backend servicesfrontend/: Web UIstorage/: Storage servicecharts/: Helm charts for deploying Craterwebsite/: Documentation website sourcegrafana-dashboards/: Grafana dashboards used by Craterdocs/: Documentation entrypoints and localization resourceshack/: Developer tooling and scripts
We welcome community contributions! If you would like to contribute to the Crater project, please follow the workflow below.
-
Fork the repository
- Visit the Crater main repository
- Click Fork in the top right corner
-
Clone your fork
# Replace YOUR_USERNAME with your GitHub username git clone https://github.com/YOUR_USERNAME/crater.git cd crater
-
Add upstream (optional)
# Add upstream repository to sync latest changes git remote add upstream https://github.com/raids-lab/crater.git # Verify remote repository configuration git remote -v
If you configure it this way,
originpoints to your fork repository, andupstreampoints to the upstream main repository.
It's recommended to create a new feature branch from the latest main branch. If you need to sync upstream changes, please first refer to the Sync Upstream Changes section to update your local main branch, then create a new feature branch:
# Create and switch to a new feature branch
git checkout -b feature/your-feature-name
# Or use this when fixing bugs
git checkout -b fix/your-bug-fixInstall Git pre-commit hooks (required for the repository workflow):
make install-hooksThen set up the environment for the component you want to work on:
- Backend: Backend Development Guide
- Frontend: Frontend Development Guide
- Storage: Storage Service Development Guide
- Website: Documentation Website Development Guide
Crater provides a unified configuration management workflow to centralize configs and create symlinks per component.
Example structure:
config/
├── backend/
│ ├── .debug.env # Backend debug environment variables
│ ├── kubeconfig # Kubernetes config file (optional)
│ └── debug-config.yaml # Backend debug configuration
├── frontend/
│ └── .env.development # Frontend development environment variables
└── storage/
├── .env # Storage service environment variables
└── config.yaml # Storage service configuration
Make targets:
-
make config-link: Create symlinks for config files (backs up existing files with.bak)make config-link CONFIG_DIR=~/develop/crater/config -
make config-status: Show config file status -
make config-unlink: Remove symlinks only -
make config-restore: Restore files from.bak
The pre-commit hook checks staged files and runs checks for the affected sub-projects:
git add <your-files>
make pre-commit-checkYou can also run checks within a sub-project (checks all files in that sub-project):
cd frontend && make pre-commit-check
cd backend && make pre-commit-check
cd storage && make pre-commit-check
cd website && make pre-commit-checkgit status
# Add changed files (please specify specific files or directories, avoid using git add .)
git add backend/pkg/handler/user.go
git add frontend/src/components/
git commit -m "feat: add new feature description"
git push origin feature/your-feature-nameCommit message convention:
feat:New featurefix:Bug fixdocs:Documentation updatesstyle:Code style changesrefactor:Code refactoringtest:Test relatedchore:Build/tool related
Then create a Pull Request on GitHub and include:
- What changed and why
- How to test
- Screenshots (if UI changes)
# Assuming you have 3 commits to squash
git rebase -i HEAD~3If you have added upstream and there are new changes in the upstream repository, you can update your local main branch as follows:
git checkout main
git fetch upstream
git merge upstream/main
# Or use the shortcut (one step)
# git pull upstream mainAfter your local main branch is updated, you can create new feature branches based on it.
If you already have a feature branch, merge updates into it:
git checkout feature/your-feature-name
git merge mainIf you haven't configured upstream, you can use GitHub's Sync fork feature to sync changes from upstream, then run git pull origin main locally.
Crater is licensed under the Apache License 2.0. See LICENSE.