# nocode — Administrator & Developer Guide

`kelseyhightower/nocode` is a satirical repository by Kelsey Hightower that makes its point by example: the repository contains no meaningful source code. This guide documents the repository as an artifact — what it contains, what it intentionally omits, and how operators and developers should approach it.

## 1. Architecture Overview

The project's "architecture" is its absence. There is no application server, no database, no message queue, no API surface, and no runtime process. The repository contains five files:

```text
kelseyhightower/nocode (commit 6c073b0)
├── Dockerfile       — Container image definition
├── README.md        — Project documentation
├── CONTRIBUTING.md  — Contributor guidelines
├── STYLE.md         — Style conventions
└── LICENSE          — License terms
```

**Data flow:** None. The container, when run, executes no logic and produces no output.

> [!NOTE]
> The `repo_type` signals for this repository are `docker-only` (65%) and `documentation` (55%). Both signals are accurate: the technical artifact is a Dockerfile; the intellectual artifact is the documentation. The absence of application code is the design, not a gap.

### Technology Stack

| Layer | Technology | Role |
|---|---|---|
| Containerization | Docker | Sole technical delivery mechanism |
| Documentation | Markdown | README, CONTRIBUTING, STYLE |
| License | LICENSE file | Governs distribution and use |
| Application code | (none) | Intentionally absent |

### Component Inventory

| Component | Path | Role |
|---|---|---|
| Container definition | `Dockerfile` | Builds the distributable image |
| Project documentation | `README.md` | Explains the project purpose |
| Contributor guidelines | `CONTRIBUTING.md` | Defines acceptance criteria for contributions |
| Style guide | `STYLE.md` | Establishes conventions for the (non-existent) codebase |
| License | `LICENSE` | Legal terms |

## 2. System Requirements

### To pull and run the image

| Requirement | Minimum |
|---|---|
| Docker Engine | Any version that supports public Docker Hub pulls |
| Network access | Required for initial pull |
| CPU | Negligible |
| Memory | Negligible |
| Storage | Minimal |

### To build from source

| Requirement | Minimum |
|---|---|
| Docker Engine | Any version with `docker build` support |
| Git | Any version |

> [!IMPORTANT]
> There is no runtime language requirement (no Python, Go, Node, Java, etc.) because there is no application code to execute.

## 3. Configuration Reference

### Configuration Files

None. The project contains no configuration files.

### Environment Variables

None. The container accepts no environment variables.

### CLI Flags

None. The image exposes no CLI interface.

> [!NOTE]
> The complete configuration surface is empty. This is verified by AST extraction (0 config keys, 0 CLI commands, 0 functions, 0 API endpoints). Any operator who encounters a configuration requirement while deploying this image has introduced external configuration at the orchestration layer, not from the project itself.

## 4. Deployment

### Docker

```bash
# Pull the image
docker pull kelseyhightower/nocode

# Run
docker run --rm kelseyhightower/nocode
```

```text
(no output — exits with code 0)
```

### Build from Source

```bash
git clone https://github.com/kelseyhightower/nocode.git
cd nocode
docker build -t nocode:local .
docker run --rm nocode:local
```

> [!TIP]
> Building from source is unnecessary for most operators — the Docker Hub image is the canonical distribution. Building locally is appropriate only for audit purposes (verifying the Dockerfile matches the published image).

### Kubernetes

The container can be deployed to Kubernetes as any other image. It will start, immediately exit with code 0, and be treated as a completed job if run as a `Job`, or continuously restarted if run as a `Deployment`.

```yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: nocode
spec:
  template:
    spec:
      containers:
        - name: nocode
          image: kelseyhightower/nocode:latest
      restartPolicy: Never
```

> [!WARNING]
> Deploying as a `Deployment` with `restartPolicy: Always` will cause the container to restart continuously, consuming orchestration overhead. Use a `Job` resource type instead.

## 5. Operations

### Monitoring

There are no health endpoints, metrics endpoints, log streams, or application events to monitor. The container process exits immediately after start.

**Recommended monitoring posture:** treat a successful `docker run` exit code of `0` as the operational health check.

```bash
docker run --rm kelseyhightower/nocode && echo "Healthy"
```

```text
Healthy
```

> [!NOTE]
> No APM, log aggregation, or tracing integration is possible — there is no application runtime to instrument.

### Scaling

The project scales horizontally to any number of instances, each of which does nothing independently and in parallel.

> [!TIP]
> If your organization's no-code compliance posture requires higher throughput of doing nothing, increase replica count freely. Resource usage per replica is negligible.

### Backup and Recovery

There is no application state to back up. The container is stateless and ephemeral by design.

### Upgrades

```bash
docker pull kelseyhightower/nocode:latest
```

No migration procedures, schema upgrades, or rolling restart strategies are required.

## 6. Performance

The container consumes no CPU and negligible memory because it runs no code. Cold start time is limited only by container scheduler overhead and image pull time on first run.

> [!TIP]
> If performance is a concern, consider not running the container at all. This is also consistent with the project's philosophy.

## 7. Security

### Threat Model

| Surface | Status |
|---|---|
| Network listeners | None — no open ports |
| Filesystem writes | None |
| Secrets / credentials | None |
| Third-party dependencies | None |
| Privilege escalation paths | None |

> [!WARNING]
> The primary security risk for this project is **supply chain substitution**: if the Docker Hub image were replaced with a malicious image under the same tag, operators pulling `kelseyhightower/nocode:latest` would receive that malicious image. Mitigate by pinning to a specific image digest rather than the `latest` tag in production environments.

### Vulnerability Surface

0 application functions, 0 API endpoints, 0 config key handlers. The AST extraction found nothing to audit. The security surface is limited to the container base image selected in the `Dockerfile`.

## 8. Developer Internals

### Repository Structure

```text
.
├── Dockerfile       — Container image definition (the sole technical artifact)
├── README.md        — Project purpose and philosophy
├── CONTRIBUTING.md  — How to contribute (spoiler: by not adding code)
├── STYLE.md         — Style conventions for the absent codebase
└── LICENSE          — Distribution license
```

### Code Patterns and Conventions

The repository enforces a single code pattern: **write no code**. `STYLE.md` documents the conventions that govern this pattern. The conventions are necessarily minimal.

### Testing Strategy

There is no test suite, because there is no code to test. This is the intended state.

> [!NOTE]
> AST extraction confirmed 0 functions, 0 classes, 0 CLI commands, 0 API endpoints, and 0 config keys across all files. The absence of these artifacts is not a gap — it is the project's deliverable.

### Module Reference

| Module | Path | Purpose |
|---|---|---|
| Container definition | `Dockerfile` | Only technical module; defines the distributable image |

No application modules exist. The extraction pipeline found 0 source characters across the entire repository.

### Contributing

1. Read `CONTRIBUTING.md` in the repository.
2. Read `STYLE.md` to understand the conventions.
3. Open a pull request that does not add code.
4. Accept that the bar for "no code" is high.

> [!CAUTION]
> The project's acceptance criteria are strict. Historical issues (#5526, #5482, #5662) requesting feature additions have been declined because implementing them would require writing code, which contradicts the project's purpose.

### Potential Improvements

The following are intentionally left unimplemented, as any implementation would violate the project's design:

- Unit tests
- Integration tests
- CI/CD pipeline
- Application logic
- Configuration management
- API surface
- Logging and telemetry

## 9. Integration Points

No integration points exist. The project exposes no API, emits no events, and consumes no external services.

> [!NOTE]
> If you are building a system that integrates with `kelseyhightower/nocode`, you are building more code than the project itself contains. Consider whether this is strictly necessary.

---

_Generated May 2026 from kelseyhightower/nocode at 6c073b0. AI-generated documentation. The library is checked by sampling (three repositories so far); this guide was not individually reviewed. Verify against the project before relying on it. Unofficial; not affiliated with or reviewed by the project._