I used to keep my nginx configs in a wiki. A shared page, "Useful Nginx Snippets," with maybe 30 config blocks, each with a heading and a paragraph of context. It was a fine wiki page, and it was a terrible reference.
The problem wasn't the content — it was the retrieval. When I'm configuring a server at 11pm and I need the exact location block that does a 301 with a regex capture, I'm not reading a wiki page. I'm in a terminal, I'm in the middle of an edit, and the wiki is a context switch: browser, search, scroll, find the block, copy, switch back. Four context switches for one config block.
So the configs moved to snippetx. Now the same block is two commands in the terminal I'm already in:
$ snippetx search redirect
b7e2d1 nginx-301-regex nginx location ~ ^/old/(.*)$ { return 301 /new/$1; }
$ snippetx copy b7e2d1 | pbcopy
No browser, no scroll, no switch. The config is in the clipboard by the time my hand is back on the terminal.
Why configs are the worst wiki content
Config blocks are a specific failure mode for wiki-based reference, and it's worth naming why:
1. They're exact, and wikis are fuzzy. A config block has to be precisely right — a missing semicolon, a wrong capture group, a directive in the wrong scope, and it doesn't work. Wiki pages are written for reading, and the act of copying from a rendered wiki page introduces errors: the markdown eats a character, the copy grabs a trailing space, the heading gets included. The terminal-to-terminal path (snippetx to clipboard) has none of that — the bytes are the bytes.
2. They're modified on use, not read on use. I rarely want the config as stored. I want it as a starting point — the 301 block with a different path, the rate-limit block with a different limit. A wiki gives me the stored version and I edit it after copying. snippetx gives me the stored version in the pipeline, where I can transform it before it hits the clipboard:
# Retrieve the rate-limit block, change the limit, copy
snippetx copy rate-limit-10rps | sed 's/10r/50r/g' | pbcopy
That last command is the whole argument. The snippet is a template in a pipeline, and the pipeline is where the modification happens. A wiki can't be a pipeline.
3. They're looked up by fragment, not by title. I rarely know the name of the config I need. I know a fragment: "the one with the proxy_set_header for the auth token." A wiki's search is title-and-full-text, and "proxy_set_header auth" matches five blocks. snippetx's search is the same, but the result is a one-liner I can scan in the terminal — the id, the name, and the first line of the block — and I pick the right one in a glance. The wiki's result is a list of page sections I have to scroll to.
What the library looks like now
About 40 nginx entries, plus a dozen of other config blocks (envoy, docker compose fragments, kubectl one-liners). The naming convention is area-purpose-detail:
nginx-301-regexnginx-rate-limit-10rpsnginx-auth-header-proxynginx-ssl-redirectcompose-postgres-16
The names are searchable by any fragment, and the language tag (nginx, compose, kubectl) lets me filter the list when I'm in a specific config context.
The migration cost, honestly
Moving the configs from the wiki to snippetx took an afternoon, and it was the most boring part: re-typing each block as a snippetx add (piping the block in from a file). The wiki's 30 blocks became 40 snippets (I added the ones I'd been meaning to save while I was in there).
The payoff showed up the first night I needed a config at an unusual hour. I was in the middle of a deploy, the terminal was open, and the config I needed was two commands away instead of four context switches away. The difference was maybe ten seconds, but the flow difference was real — I didn't leave the terminal, and I didn't lose the thread of the deploy.
The meta-point
Reference material should live in the medium you use it in. My configs are used in a terminal, so they live in a terminal. The wiki is the right home for the explanation of the configs (why the rate limit is 10rps, what the auth header does) — and the explanation can link to the snippet id. But the config itself belongs in the pipe.
The wiki tells you what the block does. snippetx gives you the block, in the terminal, ready to be modified and pasted. Both are useful. They're just not the same artifact, and keeping them in the same place is how the wiki became a terrible reference.
snippetx search nginx && snippetx copy <id> | pbcopy
More Tools
| Tool | What it does | Command |
|---|---|---|
| scaffoldx-cli | Production-ready project templates in seconds | npx scaffoldx-cli |
| dotguard | Scan .env files for exposed secrets | npx @wuchunjie/dotguard |
| gitpulse | Git repo analytics in your terminal | npx @wuchunjie/gitpulse |
| snippetx | Terminal code snippet manager | npx @wuchunjie/snippetx |
If these save you time, consider buying me a coffee. All tools are MIT-licensed, zero-dependency, and run fully offline.
Top comments (0)