nocode writes nothing, deploys nowhere, and the Dockerfile is FROM scratch

Every command in the README is an empty code block

The repository's entire technical content is six fenced code blocks, and every one of them is empty. They arrive at the expected moments. Getting Started opens with the instruction to start by not writing any code, and follows it with a blank fence, then says this is just an example application but imagine it doing anything you want, and gives you a second blank fence, then concludes that the possibilities are endless. Building the Application repeats the pattern, telling you that now that you have not done anything it is time to build, then offering another empty fence and promising you should see output that is not there. The prose is written to sound like a tutorial, and the blank fences are the punchline. The consequence for a reader is that there is no command to copy, which is the point, and also why the repository teaches you nothing beyond the joke.

The Dockerfile is FROM scratch, which is a real technique

The single line in the Dockerfile is FROM scratch, and that is the most technically informative thing in the repository:

FROM scratch

Scratch is an empty base image with no filesystem, no shell and no libc, so an image built FROM scratch contains only the binaries you copy into it. Used properly it produces minimal, auditable container images with a very small attack surface, and it is exactly what you want for a static binary. Used here it means the image has no application in it at all, which is why the deploying section can promise to deploy the application absolutely nowhere and then hand you an empty fence, and why scaling requires nothing more than another empty fence. The joke is a pun on a real practice, and the section ends with I know right? The honest framing is that this is a joke, not a recommendation: a scratch image is the right base for a program, and nocode has no program.

The Contributing section is two words, and they are the whole policy

The README's final heading is Contributing, and its entire body reads You don't. There is no separate contributing file in the repository, whose entries are CONTRIBUTING.md, Dockerfile, LICENSE, README.md and STYLE.md, so the guidance is distributed oddly, with a file named CONTRIBUTING.md present and the README's own section being a joke that contradicts it. Style is another five-word problem, since STYLE.md exists as a filename and the pack gives nothing further about its contents. The repository is MIT licensed, which is the one serious document in it, and there is a LICENSE file to match. For anyone evaluating this as a starting point for a real project, the contribution policy is the clearest signal available: this is a piece of writing, not a codebase that expects patches.

The description makes a security claim, and the claim is trivially true

The repository's own description reads The best way to write secure and reliable applications. Write nothing; deploy nowhere. Read as engineering, it is a degenerate argument. An application with no code has no memory-safety bugs, no dependency CVEs, no deserialisation flaws and no injection surface, because there is no code to introduce them. It also has no functionality, which is the part the joke relies on you to notice. The README puts the same thought in the opening line, that no code is the best way to write secure and reliable applications, and repeats it in the deploying section, where deploying absolutely nowhere is framed as the feature. The reason the joke lands is that security teams do spend real effort on attack surface reduction, and the repository compresses that entire discipline into an empty container. Taking it as a design principle is fair. Taking it as engineering advice is not.

The tree holds five files and one of them is a joke about style

The repository is tiny in a way that is easy to verify. Its entire contents are CONTRIBUTING.md, Dockerfile, LICENSE, README.md and STYLE.md, five files with no source directory, no test directory, no CI configuration, no package manifest and no lockfile. There is no build to run and no dependency to install, so there is also no supply chain to audit, which is the same argument as the Dockerfile arriving one level further along. The LICENSE file is MIT and the README is the only prose. This shape is what makes the repository easy to read in full and impossible to use, and it is worth contrasting with the way most templates are published, where a skeleton arrives with tooling attached and a dozen decisions already made for you. nocode inverts that, and the only thing it hands you is an argument.

The dates say this stopped being updated years ago

The maintenance picture is unambiguous and worth stating plainly rather than dressing up. The last push was 2024-08-07, which is more than a year before the present, and the repository has a single release, 1.0.0, tagged 2018-02-07. There is no changelog, no version history and no activity since the 2024 push. The repository is not archived, so it is still readable and still forkable, but nothing about its state suggests ongoing work, and for a repository whose entire content is a punchline that is the expected condition rather than a warning sign. The practical consequence is that if you were hoping to find a maintained starting point here, the last commit date is where that hope ends, and the 2018 version number should not be read as a sign of an actively released tool.

Editorial conclusion

Install nothing from this one, because there is nothing in it, and the repository is a joke rather than a template. The single idea worth keeping is the threat model, since a service that accepts no input and holds no state has a very small attack surface, and that is a real design goal even when nobody writes the service. If you are citing it, cite it as Kelsey Hightower's argument rather than as tooling, and do not expect the last push on 2024-08-07 or the 1.0.0 tag from 2018 to indicate activity, because neither does.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes