StackHarden publishes technical content for sysadmins, DevOps engineers, and small agencies running internet-facing infrastructure. Most pieces are written by the site owner; we are now also accepting guest contributions from working practitioners.

This page sets out what we publish, the editorial bar, and how to submit. Reading it before pitching makes a real difference — we accept pieces that already match the voice and rigour, not pieces that need to be reshaped post-hoc.

What we publish

The site has three content types:

  • Guides — long-form technical walkthroughs, typically 1,500–3,500 words, with commands tested on a stated OS and software version. Live under /guides/.
  • Checklists — verifiable, box-level checks. Each item is a command, a config flag, or a file check — not a policy or an “is this approved?” question. Live under /checklist/.
  • Learner — fundamentals pieces for early-career developers, focused on habits and reasoning. Live under /learner/.

In scope:

  • Linux server hardening (Debian / Ubuntu, RHEL family)
  • Edge configuration (Nginx, Caddy, Apache)
  • Database posture (PostgreSQL, Redis, MySQL / MariaDB)
  • Compliance translated into infrastructure work (NIS2, ISO 27001, GDPR)
  • AI security at the infrastructure layer (agentic pipelines, prompt-injection defences, audit-trail design)
  • Privacy by design at the server and application layer

Typically out of scope today:

  • Frontend frameworks
  • Generic cloud-architecture think-pieces
  • Vendor product marketing dressed as a guide
  • “Look at this new framework” pieces with no hardening or compliance angle

If your topic is adjacent but not on this list, pitch it anyway and explain the fit. Honest no’s come back faster than vague maybes.

What good looks like

Every published piece on the site is concrete, sourced, and honest about what it does not cover. The bar:

  • The commands work on the stated OS and version. This is the firmest rule. A guide that says “for Ubuntu 24.04” but was actually tested on 22.04 will be sent back. If you have not run the commands on the version you name, do not name that version.
  • Compliance mappings are honest. When a control maps to NIS2 Article 21(2)(h), say so. When it does not, do not pad. Auditors and practitioners both notice padded mappings, and both lose trust.
  • Every guide closes with a “What this guide deliberately does not cover” section. Scoping a piece tightly is a strength, not a weakness. The section also seeds the editorial backlog.
  • First-person used sparingly and only where it carries weight. Most writing is impersonal and direct. “I would” / “I have seen” land when they reflect actual experience; they are filler when they do not.
  • No marketing language. No “powerful”, no “robust”, no “seamless”, no “best-in-class”. The work is the work; describe it plainly.

Editorial principles

A few standing rules shape the calendar. They are not contributor requirements but they affect which pitches we say yes to:

  • We alternate ops-facing and developer-facing pieces where the backlog allows. If you can write for either audience, flag which you are pitching for.
  • We do not run two consecutive pieces on the same narrow topic. Two PostgreSQL pieces back to back makes the site feel monothematic.
  • We keep room each quarter for a response piece — a new directive, a published incident, a vendor announcement worth reacting to. Pitches that are timely move faster.

Format and front matter

Draft the piece as a single markdown file. We will place it under the right section on the site at integration time — your filename should be a short kebab-case slug (no date prefix). Including the front matter below in your draft helps us review faster and shows you have read this page.

Front matter we use:

 1---
 2title: "Plain title in title case"
 3date: 2026-06-10
 4description: "One sentence — appears on the home-page cards and on social previews."
 5tags: ["postgres", "tls", "hardening"]
 6categories: ["guides"]
 7series: ["compliance"]    # optional — only for connected pieces
 8author: "Your Name"
 9author_bio: "Short bio — what you do, where, what you are known for. 2–3 sentences max."
10author_link: "https://your-site.example/"
11draft: true               # stays true until commands tested on the stated OS
12weight: 40                # optional — only for in-series ordering
13nis2_relevant: true       # optional — flags the piece on the NIS2 series page
14---

Body conventions:

  • Sentence case for ## headings and ### subheadings.
  • Fenced code blocks with language tags (```bash, ```nginx, ```sql) so highlighting renders.
  • Cross-links to other site pieces use root-relative URLs (/guides/foo/), never absolute production URLs.
  • Compliance callouts use the {{< compliance >}} shortcode — see any guide in /guides/ for examples.
  • Inline code for any command, file path, config flag, or environment variable. The site reads as a technical document; that density is the voice.

How to submit

Everything goes through [email protected]. Two stages:

  1. Pitch first. Email a 150–300-word pitch. Include:

    • Working title
    • Audience (ops, developer, both)
    • Bullet outline of what the piece will cover
    • Which OS and software versions you will test on
    • Anything you have already written that demonstrates the voice (a blog post, a previous guide, a thorough README — not a CV)

  2. Draft by email. If we green-light the pitch, write your piece as a single markdown file with the front matter described below and email it back as an attachment. Editorial review happens against this page’s standards — voice, scoping, command accuracy, honest compliance mapping. We will come back with specific edits or a yes; once we agree the piece is ready, we handle the integration into the site.

We aim to respond to pitches within a week. We do not always accept — often the answer is “good topic, similar piece in flight” or “scope narrower than the site usually publishes”. Both are honest.

What you get

  • Byline. Your name appears in the article’s post meta alongside reading time and word count.
  • Bio block. A 2–3-sentence bio at the foot of the article, with one outbound link (your own site, GitHub profile, or LinkedIn).
  • First-publication credit and indefinite hosting. You retain copyright; by submitting you grant us first-publication rights and a licence to host the piece indefinitely. If you later republish elsewhere, please credit StackHarden as the original source. We will do the same on any republication request.

We do not pay per piece today. This is a contributor programme for working practitioners who want a credible, well-edited venue — not a paid commissioning model. If that changes, it will be reflected on this page.

Questions

Email [email protected]. Real responses, no auto-replies.