wild-cloud/wild-cloud-dev
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Update docs.

Browse Source
This commit is contained in:
Paul Payne
2025-10-12 00:34:23 +00:00
parent 998b6fa369
commit 72176d5401
6 changed files with 231 additions and 426 deletions
Download Patch File Download Diff File Expand all files Collapse all files

205
CLAUDE.md
View File

@@ -4,18 +4,197 @@ This file provides guidance to Claude Code (claude.ai/code) when working with co
## Project Overview
This project is called "Wild Cloud Central". It consists of the following components:
This project is called "Wild Cloud". Wild Cloud is a platform for managing and orchestrating cloud-native applications on local networks using a network appliance called "Wild Central".
- **Wild Daemon**:
- @wild-central-api/README.md
- A web server that provides an API for managing Wild Cloud instances.
- Wild CLI:
- @wild-cli/README.md
- A command-line interface for interacting with the Wild Daemon and managing Wild Cloud clusters.
- Wild App:
- @wild-web-app/README.md
- A web-based interface for managing Wild Cloud instances, hosted on Wild Central.
Wild Central is a lightweight server that runs on a local machine (e.g., a Raspberry Pi) and provides an API for users to manage their Wild Cloud instances. The Wild Cloud API is implemented in the wild-central-api project. @wild-central-api/README.md . Wild Central devices can be set up using our apt package implemented in the wild-central project. @wild-central/README.md
A Wild Cloud instance is a kubernetes (k8s) environment that runs Wild Cloud services and applications. Wild Cloud instances can be created, managed, and monitored using the Wild Cloud API running on a Wild Central device.
Wild Cloud applications are custom packages designed to be deployed to Wild Cloud instances. They consist of kustomize templates and a Wild Cloud app manifest file that describes the application and how it should be deployed configured and deployed in a Wild Cloud instance. Wild Cloud applications are stored in a "Wild Directory". The directory contained in the wild-directory folder is the official Wild Directory. @wild-directory/README.md
The Wild Cloud API maintains data for each Wild Cloud instance in its configured WILD_API_DATA_DIR. A data directory is intended to be checked into version control (e.g., git) to track changes to the configuration of Wild Cloud instances and their deployed applications over time. These are designed to follow infrastructure-as-code principles, allowing experienced devops users to manage their Wild Cloud instances using familiar tools and workflows.
We provide a command-line interface (CLI) tool called Wild CLI, implemented in the wild-cli project, that allows users to interact with the Wild Cloud API and manage their Wild Cloud instances from the terminal. This allows users to automate tasks and integrate Wild Cloud management into their existing workflows. @wild-cli/README.md
To make Wild Cloud more accessible to less-experienced users, the Wild Central device hosts a web-based interface for managing Wild Cloud instances, which is implemented in the wild-web-app project. @wild-web-app/README.md
## Additional Documentation
### Info about Talos
- @ai/talos-v1.11/README.md
- @ai/talos-v1.11/architecture-and-components.md
- @ai/talos-v1.11/cli-essentials.md
- @ai/talos-v1.11/cluster-operations.md
- @ai/talos-v1.11/discovery-and-networking.md
- @ai/talos-v1.11/etcd-management.md
- @ai/talos-v1.11/bare-metal-administration.md
- @ai/talos-v1.11/troubleshooting-guide.md
## Implementation Philosophy
## Core Philosophy
Embodies a Zen-like minimalism that values simplicity and clarity above all. This approach reflects:
- **Wabi-sabi philosophy**: Embracing simplicity and the essential. Each line serves a clear purpose without unnecessary embellishment.
- **KISS**: The solution should be as simple as possible, but no simpler.
- **YAGNI**: Avoid building features or abstractions that aren't immediately needed. The code handles what's needed now rather than anticipating every possible future scenario.
- **Trust in emergence**: Complex systems work best when built from simple, well-defined components that do one thing well.
- **Pragmatic trust**: The developer trusts external systems enough to interact with them directly, handling failures as they occur rather than assuming they'll happen.
- **Consistency is key**: Uniform patterns and conventions make the codebase easier to understand and maintain. If you introduce a new pattern, make sure it's consistently applied. There should be one obvious way to do things.
This development philosophy values clear, concise documentation, readable code, and belief that good architecture emerges from simplicity rather than being imposed through complexity.
## Core Design Principles
### 1. Ruthless Simplicity
- **KISS principle taken to heart**: Keep everything as simple as possible, but no simpler
- **Minimize abstractions**: Every layer of abstraction must justify its existence
- **Start minimal, grow as needed**: Begin with the simplest implementation that meets current needs
- **Avoid future-proofing**: Don't build for hypothetical future requirements
- **Question everything**: Regularly challenge complexity in the codebase
### 2. Architectural Integrity with Minimal Implementation
- **Preserve key architectural patterns**: Maintain clear boundaries and responsibilities
- **Simplify implementations**: Maintain pattern benefits with dramatically simpler code
- **Scrappy but structured**: Lightweight implementations of solid architectural foundations
- **End-to-end thinking**: Focus on complete flows rather than perfect components
### 3. Library vs Custom Code
Choosing between custom code and external libraries is a judgment call that evolves with your requirements. There's no rigid rule - it's about understanding trade-offs and being willing to revisit decisions as needs change.
#### The Evolution Pattern
Your approach might naturally evolve:
- **Start simple**: Custom code for basic needs (20 lines handles it)
- **Growing complexity**: Switch to a library when requirements expand
- **Hitting limits**: Back to custom when you outgrow the library's capabilities
This isn't failure - it's natural evolution. Each stage was the right choice at that time.
#### When Custom Code Makes Sense
Custom code often wins when:
- The need is simple and well-understood
- You want code perfectly tuned to your exact requirements
- Libraries would require significant "hacking" or workarounds
- The problem is unique to your domain
- You need full control over the implementation
#### When Libraries Make Sense
Libraries shine when:
- They solve complex problems you'd rather not tackle (auth, crypto, video encoding)
- They align well with your needs without major modifications
- The problem is well-solved with mature, battle-tested solutions
- Configuration alone can adapt them to your requirements
- The complexity they handle far exceeds the integration cost
#### Making the Judgment Call
Ask yourself:
- How well does this library align with our actual needs?
- Are we fighting the library or working with it?
- Is the integration clean or does it require workarounds?
- Will our future requirements likely stay within this library's capabilities?
- Is the problem complex enough to justify the dependency?
#### Recognizing Misalignment
Watch for signs you're fighting your current approach:
- Spending more time working around the library than using it
- Your simple custom solution has grown complex and fragile
- You're monkey-patching or heavily wrapping a library
- The library's assumptions fundamentally conflict with your needs
#### Stay Flexible
Remember that complexity isn't destroyed, only moved. Libraries shift complexity from your code to someone else's - that's often a great trade, but recognize what you're doing.
The key is avoiding lock-in. Keep library integration points minimal and isolated so you can switch approaches when needed. There's no shame in moving from custom to library or library to custom. Requirements change, understanding deepens, and the right answer today might not be the right answer tomorrow. Make the best decision with current information, and be ready to evolve.
## Technical Implementation Guidelines
### API Layer
- Implement only essential endpoints
- Minimal middleware with focused validation
- Clear error responses with useful messages
- Consistent patterns across endpoints
### Storage
- Prefer simple file storage
- Simple schema focused on current needs
## Development Approach
### Vertical Slices
- Implement complete end-to-end functionality slices
- Start with core user journeys
- Get data flowing through all layers early
- Add features horizontally only after core flows work
### Iterative Implementation
- 80/20 principle: Focus on high-value, low-effort features first
- One working feature > multiple partial features
- Validate with real usage before enhancing
- Be willing to refactor early work as patterns emerge
### Testing Strategy
- Focus on critical path testing initially
- Add unit tests for complex logic and edge cases
- Testing pyramid: 60% unit, 30% integration, 10% end-to-end
### Error Handling
- Handle common errors robustly
- Log detailed information for debugging
- Provide clear error messages to users
- Fail fast and visibly during development
## Decision-Making Framework
When faced with implementation decisions, ask these questions:
1. **Necessity**: "Do we actually need this right now?"
2. **Simplicity**: "What's the simplest way to solve this problem?"
3. **Directness**: "Can we solve this more directly?"
4. **Value**: "Does the complexity add proportional value?"
5. **Maintenance**: "How easy will this be to understand and change later?"
## Areas to Embrace Complexity
Some areas justify additional complexity:
1. **Security**: Never compromise on security fundamentals
2. **Data integrity**: Ensure data consistency and reliability
3. **Core user experience**: Make the primary user flows smooth and reliable
4. **Error visibility**: Make problems obvious and diagnosable
## Areas to Aggressively Simplify
Push for extreme simplicity in these areas:
1. **Internal abstractions**: Minimize layers between components
2. **Generic "future-proof" code**: Resist solving non-existent problems
3. **Edge case handling**: Handle the common cases well first
4. **Framework usage**: Use only what you need from frameworks
5. **State management**: Keep state simple and explicit
## Remember
- It's easier to add complexity later than to remove it
- Code you don't write has no bugs
- Favor clarity over cleverness
- The best code is often the simplest
This philosophy document serves as the foundational guide for all implementation decisions in the project.
Read all of the following for context:
- @ai/BUILDING_WILD_CENTRAL.md

46
README.md
View File

@@ -1,12 +1,44 @@
# Wild Cloud Development Environment
## Support
- **Documentation**: See `docs/` directory for detailed guides
- **Issues**: Report problems on the project issue tracker
- **API Reference**: Available at `/api/v1/` endpoints when service is running
## Documentation
- [Developer Guide](docs/DEVELOPER.md) - Development setup, testing, and API reference
- [Maintainer Guide](docs/MAINTAINER.md) - Package management and repository deployment
## Setup
### Prerequisites
- Go 1.21+
- Docker (for testing)
- make
```bash
sudo apt update
sudo apt install make direnv
echo 'eval "$(direnv hook bash)"' >> $HOME/.bashrc
source $HOME/.bashrc
# Node.js and pnpm setup
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
source $HOME/.bashrc
nvm install --lts
curl -fsSL https://get.pnpm.io/install.sh | sh -
source $HOME/.bashrc
pnpm install -g @anthropic-ai/claude-code
# Golang setup
wget https://go.dev/dl/go1.24.5.linux-arm64.tar.gz
sudo tar -C /usr/local -xzf ./go1.24.5.linux-arm64.tar.gz
echo 'export PATH="$PATH:$HOME/go/bin:/usr/local/go/bin"' >> $HOME/.bashrc
source $HOME/.bashrc
rm ./go1.24.5.linux-arm64.tar.gz
go install -v github.com/go-delve/delve/cmd/dlv@latest
# Python setup
curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env
uv sync
# Runtime dependencies
./scripts/install-wild-cloud-dependencies.sh

260
ai/BUILDING_WILD_CENTRAL.md
View File

@@ -1,260 +0,0 @@
# Building Wild Cloud Central
The first version of Wild Cloud, the Proof of Concept version (v.PoC), was built as a collection of shell scripts that users would run from their local machines. This works well for early adopters who are comfortable with the command line, Talos, and Kubernetes.
To make Wild Cloud more accessible to a broader audience, we are developing Wild Central. Central is a single-purpose machine run on a LAN that will deliver:
- Wild Daemon: A lightweight service that runs on a local machine (e.g., a Raspberry Pi) to manage Wild Cloud instances on the local network.
- Wild App: A web-based interface (to Wild Daemon) for managing Wild Cloud instances.
- Wild CLI: A command-line interface (to Wild Daemon) for advanced users who prefer to manage Wild Cloud from the terminal.
## Background info
### Info about Wild Cloud v.PoC
- @docs/agent-context/wildcloud-v.PoC/README.md
- @docs/agent-context/wildcloud-v.PoC/overview.md
- @docs/agent-context/wildcloud-v.PoC/project-architecture.md
- @docs/agent-context/wildcloud-v.PoC/bin-scripts.md
- @docs/agent-context/wildcloud-v.PoC/configuration-system.md
- @docs/agent-context/wildcloud-v.PoC/setup-process.md
- @docs/agent-context/wildcloud-v.PoC/apps-system.md
### Info about Talos
- @docs/agent-context/talos-v1.11/README.md
- @docs/agent-context/talos-v1.11/architecture-and-components.md
- @docs/agent-context/talos-v1.11/cli-essentials.md
- @docs/agent-context/talos-v1.11/cluster-operations.md
- @docs/agent-context/talos-v1.11/discovery-and-networking.md
- @docs/agent-context/talos-v1.11/etcd-management.md
- @docs/agent-context/talos-v1.11/bare-metal-administration.md
- @docs/agent-context/talos-v1.11/troubleshooting-guide.md
## Architecture
### Old v.PoC Architecture
- WC_ROOT: The scripts used to set up and manage the Wild Cloud cluster. Currently, this is a set of shell scripts in $WC_ROOT/bin.
- WC_HOME: During setup, the user creates a Wild Cloud project directory (WC_HOME) on their local machine. This directory holds all configuration, secrets, and k8s manifests for their specific Wild Cloud deployment.
- Wild Cloud Apps Directory: The Wild Cloud apps are stored in the `apps/` directory within the WC_ROOT repository. Users can deploy these apps to their cluster using the scripts in WC_ROOT/bin.
- dnsmasq server: Scripts help the operator set up a dnsmasq server on a separate machine to provide LAN DNS services during node bootstrapping.
### New Wild Central Architecture
#### wildd: The Wild Cloud Daemon
wildd is a long-running service that provides an API and web interface for managing one or more Wild Cloud clusters. It runs on a dedicated device within the user's network.
wildd replaces functionality from the v.PoC scripts and the dnsmasq server. It is one API for managing multiple wild cloud instances on the LAN.
Both wild-app and wild-cli communicate with wildd to perform actions.
See: @daemon/BUILDING_WILD_DAEMON.md
#### wild-app
The web application that provides the user interface for Wild Cloud on Wild Central. It communicates with wildd to perform actions and display information.
See: @/app/BUILDING_WILD_APP.md
#### wild-cli
A command-line interface for advanced users who prefer to manage Wild Cloud from the terminal. It communicates with wildd to perform actions.
Mirrors all of the wild-* scripts from v.PoC, but adapted for the new architecture:
- One golang client (wild-cli) replaces many bash scripts (wild-*).
- Wrapper around wildd API instead of direct file manipulation.
- Multi-cloud: v.PoC scripts set the instance context with WC_HOME environment variable. In Central, wild-cli follows the "context" pattern like kubectl and talosctl, using `--context` or `WILD_CONTEXT` to select which wild cloud instance to manage, or defaulting to the "current" context.
See: @cli/BUILDING_WILD_CLI.md
#### Wild Central Data
Configured with $WILD_CENTRAL_DATA environment variable (default: /var/lib/wild-central).
Replaces multiple WC_HOMEs. All wild clouds managed on the LAN are configured here. These are still in easy to read YAML format and can be edited directly or through the webapp.
Wild Central data also holds the local app directory, logs, and artifacts, and overall state data.
#### Wild Cloud Apps Directory
The Wild Cloud apps are stored in the `apps/` directory within the WC_ROOT repository. Users can deploy these apps to their cluster using the webapp or wild-cli.
#### dnsmasq server
The Wild Daemon (wildd) includes functionality to manage a dnsmasq server on the same device, providing LAN DNS services during node bootstrapping.
## Packaging and Installation
Ultimately, the daemon, app, and cli will be packaged together for easy installation on a Raspberry Pi or similar device.
See @ai/WILD_CENTRAL_PACKAGING.md
## Implementation Philosophy
## Core Philosophy
Embodies a Zen-like minimalism that values simplicity and clarity above all. This approach reflects:
- **Wabi-sabi philosophy**: Embracing simplicity and the essential. Each line serves a clear purpose without unnecessary embellishment.
- **KISS**: The solution should be as simple as possible, but no simpler.
- **YAGNI**: Avoid building features or abstractions that aren't immediately needed. The code handles what's needed now rather than anticipating every possible future scenario.
- **Trust in emergence**: Complex systems work best when built from simple, well-defined components that do one thing well.
- **Pragmatic trust**: The developer trusts external systems enough to interact with them directly, handling failures as they occur rather than assuming they'll happen.
- **Consistency is key**: Uniform patterns and conventions make the codebase easier to understand and maintain. If you introduce a new pattern, make sure it's consistently applied. There should be one obvious way to do things.
This development philosophy values clear, concise documentation, readable code, and belief that good architecture emerges from simplicity rather than being imposed through complexity.
## Core Design Principles
### 1. Ruthless Simplicity
- **KISS principle taken to heart**: Keep everything as simple as possible, but no simpler
- **Minimize abstractions**: Every layer of abstraction must justify its existence
- **Start minimal, grow as needed**: Begin with the simplest implementation that meets current needs
- **Avoid future-proofing**: Don't build for hypothetical future requirements
- **Question everything**: Regularly challenge complexity in the codebase
### 2. Architectural Integrity with Minimal Implementation
- **Preserve key architectural patterns**: Maintain clear boundaries and responsibilities
- **Simplify implementations**: Maintain pattern benefits with dramatically simpler code
- **Scrappy but structured**: Lightweight implementations of solid architectural foundations
- **End-to-end thinking**: Focus on complete flows rather than perfect components
### 3. Library vs Custom Code
Choosing between custom code and external libraries is a judgment call that evolves with your requirements. There's no rigid rule - it's about understanding trade-offs and being willing to revisit decisions as needs change.
#### The Evolution Pattern
Your approach might naturally evolve:
- **Start simple**: Custom code for basic needs (20 lines handles it)
- **Growing complexity**: Switch to a library when requirements expand
- **Hitting limits**: Back to custom when you outgrow the library's capabilities
This isn't failure - it's natural evolution. Each stage was the right choice at that time.
#### When Custom Code Makes Sense
Custom code often wins when:
- The need is simple and well-understood
- You want code perfectly tuned to your exact requirements
- Libraries would require significant "hacking" or workarounds
- The problem is unique to your domain
- You need full control over the implementation
#### When Libraries Make Sense
Libraries shine when:
- They solve complex problems you'd rather not tackle (auth, crypto, video encoding)
- They align well with your needs without major modifications
- The problem is well-solved with mature, battle-tested solutions
- Configuration alone can adapt them to your requirements
- The complexity they handle far exceeds the integration cost
#### Making the Judgment Call
Ask yourself:
- How well does this library align with our actual needs?
- Are we fighting the library or working with it?
- Is the integration clean or does it require workarounds?
- Will our future requirements likely stay within this library's capabilities?
- Is the problem complex enough to justify the dependency?
#### Recognizing Misalignment
Watch for signs you're fighting your current approach:
- Spending more time working around the library than using it
- Your simple custom solution has grown complex and fragile
- You're monkey-patching or heavily wrapping a library
- The library's assumptions fundamentally conflict with your needs
#### Stay Flexible
Remember that complexity isn't destroyed, only moved. Libraries shift complexity from your code to someone else's - that's often a great trade, but recognize what you're doing.
The key is avoiding lock-in. Keep library integration points minimal and isolated so you can switch approaches when needed. There's no shame in moving from custom to library or library to custom. Requirements change, understanding deepens, and the right answer today might not be the right answer tomorrow. Make the best decision with current information, and be ready to evolve.
## Technical Implementation Guidelines
### API Layer
- Implement only essential endpoints
- Minimal middleware with focused validation
- Clear error responses with useful messages
- Consistent patterns across endpoints
### Storage
- Prefer simple file storage
- Simple schema focused on current needs
## Development Approach
### Vertical Slices
- Implement complete end-to-end functionality slices
- Start with core user journeys
- Get data flowing through all layers early
- Add features horizontally only after core flows work
### Iterative Implementation
- 80/20 principle: Focus on high-value, low-effort features first
- One working feature > multiple partial features
- Validate with real usage before enhancing
- Be willing to refactor early work as patterns emerge
### Testing Strategy
- Focus on critical path testing initially
- Add unit tests for complex logic and edge cases
- Testing pyramid: 60% unit, 30% integration, 10% end-to-end
### Error Handling
- Handle common errors robustly
- Log detailed information for debugging
- Provide clear error messages to users
- Fail fast and visibly during development
## Decision-Making Framework
When faced with implementation decisions, ask these questions:
1. **Necessity**: "Do we actually need this right now?"
2. **Simplicity**: "What's the simplest way to solve this problem?"
3. **Directness**: "Can we solve this more directly?"
4. **Value**: "Does the complexity add proportional value?"
5. **Maintenance**: "How easy will this be to understand and change later?"
## Areas to Embrace Complexity
Some areas justify additional complexity:
1. **Security**: Never compromise on security fundamentals
2. **Data integrity**: Ensure data consistency and reliability
3. **Core user experience**: Make the primary user flows smooth and reliable
4. **Error visibility**: Make problems obvious and diagnosable
## Areas to Aggressively Simplify
Push for extreme simplicity in these areas:
1. **Internal abstractions**: Minimize layers between components
2. **Generic "future-proof" code**: Resist solving non-existent problems
3. **Edge case handling**: Handle the common cases well first
4. **Framework usage**: Use only what you need from frameworks
5. **State management**: Keep state simple and explicit
## Remember
- It's easier to add complexity later than to remove it
- Code you don't write has no bugs
- Favor clarity over cleverness
- The best code is often the simplest
This philosophy document serves as the foundational guide for all implementation decisions in the project.

102
ai/WILD_CENTRAL_PACKAGING.md
View File

@@ -1,102 +0,0 @@
# Packaging Wild Central
## Desired Experience
This is the desired experience for installing Wild Cloud Central on a fresh Debian/Ubuntu system:
### APT Repository (Recommended)
```bash
# Download and install GPG key
curl -fsSL https://mywildcloud.org/apt/wild-cloud-central.gpg | sudo tee /usr/share/keyrings/wild-cloud-central-archive-keyring.gpg > /dev/null
# Add repository (modern .sources format)
sudo tee /etc/apt/sources.list.d/wild-cloud-central.sources << 'EOF'
Types: deb
URIs: https://mywildcloud.org/apt
Suites: stable
Components: main
Signed-By: /usr/share/keyrings/wild-cloud-central-archive-keyring.gpg
EOF
# Update and install
sudo apt update
sudo apt install wild-cloud-central
```
### Manual Installation
Download the latest `.deb` package from the [releases page](https://github.com/wildcloud/wild-central/releases) and install:
```bash
sudo dpkg -i wild-cloud-central_*.deb
sudo apt-get install -f # Fix any dependency issues
```
## Quick Start
1. **Configure the service** (optional):
```bash
sudo cp /etc/wild-cloud-central/config.yaml.example /etc/wild-cloud-central/config.yaml
sudo nano /etc/wild-cloud-central/config.yaml
```
2. **Start the service**:
```bash
sudo systemctl enable wild-cloud-central
sudo systemctl start wild-cloud-central
```
3. **Access the web interface**:
Open http://your-server-ip in your browser
## Developer tooling
Makefile commands for packaging:
Build targets (compile binaries):
make build - Build for current architecture
make build-arm64 - Build arm64 binary
make build-amd64 - Build amd64 binary
make build-all - Build all architectures
Package targets (create .deb packages):
make package - Create .deb package for current arch
make package-arm64 - Create arm64 .deb package
make package-amd64 - Create amd64 .deb package
make package-all - Create all .deb packages
Repository targets:
make repo - Build APT repository from packages
make deploy-repo - Deploy repository to server
Quality assurance:
make check - Run all checks (fmt + vet + test)
make fmt - Format Go code
make vet - Run go vet
make test - Run tests
Development:
make run - Run application locally
make clean - Remove all build artifacts
make deps-check - Verify and tidy dependencies
make version - Show build information
make install - Install to system
Directory structure:
build/ - Intermediate build artifacts
dist/bin/ - Final binaries for distribution
dist/packages/ - OS packages (.deb files)
dist/repositories/ - APT repository for deployment
Example workflows:
make check && make build - Safe development build
make clean && make repo - Full release build

41
ai/wildcloud-v.PoC/project-architecture.md
View File

@@ -59,47 +59,6 @@ apps/
- **AI/ML**: vLLM
- **Infrastructure**: Memcached, NFS
### `/setup/` - Infrastructure Templates
**Purpose**: Cluster and service deployment templates
```
setup/
├── README.md
├── cluster-nodes/ # Talos node configuration
│ ├── init-cluster.sh # Cluster initialization script
│ ├── patch.templates/ # Node-specific config templates
│ │ ├── controlplane.yaml # Control plane template
│ │ └── worker.yaml # Worker node template
│ └── talos-schemas.yaml # Version mappings
├── cluster-services/ # Core Kubernetes services
│ ├── README.md
│ ├── metallb/ # Load balancer
│ ├── traefik/ # Ingress controller
│ ├── cert-manager/ # Certificate management
│ ├── longhorn/ # Distributed storage
│ ├── coredns/ # DNS resolution
│ ├── externaldns/ # DNS record management
│ ├── kubernetes-dashboard/ # Web UI
│ └── ...
├── dnsmasq/ # DNS and PXE boot server
├── home-scaffold/ # User directory templates
└── operator/ # Additional operator tools
```
### `/experimental/` - Development Projects
**Purpose**: Experimental features and development tools
```
experimental/
├── daemon/ # Go API daemon
│ ├── main.go # API server
│ ├── Makefile # Build automation
│ └── README.md
└── app/ # React dashboard
├── src/ # React source code
├── package.json # Dependencies
├── pnpm-lock.yaml # Lock file
└── README.md
```
### `/scripts/` - Utility Scripts
**Purpose**: Installation and utility scripts
```

3
docs/SETUP.md
View File

@@ -1,3 +0,0 @@
# Setting Up Your Wild Cloud
Visit https://mywildcloud.org/get-started for full wild cloud setup instructions.