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:

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

Component Inventory

2. System Requirements

To pull and run the image

To build from source

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

# Pull the image
docker pull kelseyhightower/nocode

# Run
docker run --rm kelseyhightower/nocode

(no output — exits with code 0)

Build from Source

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.

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.

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

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

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

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

.
├── 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

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.