I build Rust services, and fix the ones other people depend on.

DNS internals, backend services, and developer infrastructure. four changes merged into hickory-dns (opens in a new tab) and oxish (opens in a new tab), one more in review.

2026 — built with Next.js, served as static files.

Open source

Changes I made to Rust projects I do not own. Every entry links to the pull request it describes. Where the same change was also landed on a release branch, that backport is listed inside the entry rather than counted as separate work.

hickory-dns/hickory-dns (opens in a new tab)a DNS client, server, and resolver written in Rust

Let the server skip privilege dropping inside a namespace
Merged
bin · server startupMerged 30 June 2026+17−52 files
Problem
The server follows the usual Unix pattern: start as root, bind the privileged port, then call setuid/setgid down to an unprivileged user. Inside a Linux user namespace the process looks like root, so the uid check passes — but the host /etc/passwd is not mounted, so the getpwnam("nobody") lookup that follows returns NULL and startup aborts.
Change
Added a drop_privileges config field defaulting to true, and threaded it through to the Unix startup path so the privilege-dropping step can be skipped. Existing deployments are unaffected; the flag has to be set deliberately.
Why it matters
Deckard, the project's own DNS conformance test suite, runs the server inside exactly such a namespace. Before this, there was no supported way to run Hickory there — the only options were patching the binary or not testing it at all.
#3762 (opens in a new tab)Issue #3094 (opens in a new tab)Same change on release/0.26 (#3763) (opens in a new tab)
My write-up of this change (opens in a new tab)
Say which Cargo feature a zone store needs, instead of calling it unknown
Merged
bin · config parsingMerged 31 July 2026+50−11 file
Problem
Store types in the config enum are behind Cargo features. Writing type = "recursor" in a binary built without --features recursor made serde fail at the enum tag: unknown variant `recursor`, expected `forward` or `default`. The store is not unknown — it was compiled out, and the message sent people looking for a typo.
Change
Paired each feature-gated variant with a fallback variant holding serde's IgnoredAny, compiled in when the feature is off. The config now parses, and the failure surfaces later from the store loader as: store type `recursor` requires the `recursor` Cargo feature, which was not enabled when this binary was built. Same treatment for forward, blocklist and sqlite.
Why it matters
It moves the error from the parser, which only knows about tags, to the place that knows why the variant is missing. The wording now names the fix.
#3808 (opens in a new tab)Issue #3775 (opens in a new tab)Same change on release/0.26 (#3810) (opens in a new tab)
Stop a config test from panicking in builds without DNSSEC
Merged
bin · config testsMerged 10 August 2026+7−01 file
Problem
test_reject_unknown_fields walks the example configs and skips the ones a build cannot parse. The skip logic only looked at store types, so example_recursor_dnssec.toml slipped through on builds without __dnssec and the test panicked on the ValidateWithStaticKey policy.
Change
Extended the skip check to the dnssec_policy field, matching the shape of the existing store-type checks.
Why it matters
Seven lines, but it is the difference between a feature combination being testable and the suite failing for a reason unrelated to what it is testing.
#3823 (opens in a new tab)Issue #3811 (opens in a new tab)
Make OPT record equality agree with its own hash
In review
proto · EDNS record dataOpened 12 September 2026+93−341 file
Problem
PartialEq for OPT counted how many of its options the other record contained. contains() ignores multiplicity, so [A, A] compared equal to [A, B] — and swapping the operands gave the opposite answer. Hash, meanwhile, had sorted the options since commit 27109e3. Two records could therefore be equal and hash differently, which breaks the Hash/Eq contract that HashMap and HashSet rely on — and RData derives both, so anything keyed on record data inherits it.
Change
Made the options vector private and kept it in canonical order at the two places that can change it, so the derived PartialEq, Hash and Ord all agree. Order still does not matter; repeated options now do. Added a test for the duplicate case and an options() accessor so callers keep read access.
Why it matters
RFC 6891 §6.1.2 gives an option's position no significance, so order-independent comparison is correct — but it has to be implemented in a way that equality and hashing cannot disagree.
Approved by the maintainer. Still open: a reviewer raised that re-ordering options would change the bytes re-encoded for TSIG MAC verification, so the canonical-order approach is under discussion.
#3914 (opens in a new tab)

djc/oxish (opens in a new tab)an SSH server written in Rust

Repair the fuzz target and make CI build it
Merged
fuzz · CIMerged 23 August 2026+31−44 files
Problem
The fuzz crate had stopped compiling after the protocol message types moved into submodules. Nothing noticed, because fuzz/ declares its own workspace — so cargo check --all-targets and cargo clippy --all-targets never reach it.
Change
Fixed the decode target's imports against the new module paths, added the two dependencies that oxish-proto had picked up to the fuzz lockfile, moved the crate to edition 2024 to match the workspace, and added a nightly CI job running cargo fuzz build.
Why it matters
The broken target was the visible bug; the missing CI job was the reason it stayed broken. Fixing only the first would have let it rot again.
#274 (opens in a new tab)Issue #273 (opens in a new tab)

Hickory DNS and oxish are maintained projects with their own designs and their own reviewers. What is mine in the list above is each individual change and the reasoning for it — not the projects themselves.

Work

four things I designed, built and keep running. Ordered by how much backend and systems engineering they actually evidence, which is not the same as how new they are.

Feature Flag Service
Self-hosted feature flags with targeting, rollouts and an SDK endpoint.
Deployed · open sourceRust · Axum · PostgreSQL · SQLx · React
OSSPath
A map of the Rust ecosystem, built from what real projects actually depend on.
Deployed · open sourceTypeScript · Next.js · PostgreSQL · Prisma · Cloudflare
LoopUpward
A personal planning system where progress on small things rolls up into the large ones.
Deployed · open sourceRust · TypeScript · PostgreSQL · Docker
Romyq
A terminal tool that keeps a long AI-assisted coding session pointed at the original goal.
Released · open source · Python, not RustPython · Local-first

Smaller published things

rust-kv-store (opens in a new tab)RustA key-value store on an append-only log — replay on startup, compaction, no dependencies. Written to work through the durability trade-offs rather than to be used.
axum-api-template (opens in a new tab)RustA REST API starting point with Axum, Postgres, JWT auth and migrations wired together.
solaudit (opens in a new tab)Published crateRetry-safety analyser for Solana transactions, using state diffing to find what a replayed transaction would change.
notez · smart_tasker (opens in a new tab)Published cratesTwo small command-line tools on crates.io, both standard-library-only exercises in doing without dependencies.

Writing

Write-ups of things that took longer than they should have. Longer pieces are on the blog; the ones worth pointing at directly are listed here.

July 2026First OSS contribution in Hickory-DNSWhy a DNS server that starts fine on a host dies instantly inside a Linux user namespace, and what it took to get the fix accepted upstream. (opens in a new tab)

The rest of it

blog.adarshrust.com (opens in a new tab)longer write-ups
notes.adarshrust.com (opens in a new tab)working notebook

Profile

Rust backend and systems engineer, working remotely. Everything on this site links to the code or the pull request behind it, so none of it has to be taken on trust.

What I work on

Backend services in Rust — Axum and Postgres, auth, rate limiting, and the parts that have to stay correct when they are called concurrently. Alongside that, the layer underneath: DNS server internals, Unix process startup and privilege handling, protocol record types, Cargo feature boundaries, and the test and fuzz infrastructure that keeps those honest.

The upstream work is where that is easiest to check. four changes of mine are merged into Hickory DNS (opens in a new tab) and oxish (opens in a new tab), each one reviewed by maintainers who did not have to accept it.

Read the contributions

Contact

[email protected]Email
GitHub (opens in a new tab)source for everything here
crates.io (opens in a new tab)published crates
Blog (opens in a new tab)longer write-ups
Notes (opens in a new tab)working notebook

2026 — built with Next.js, served as static files.

Feature Flag Service

Self-hosted feature flags with targeting, rollouts and an SDK endpoint.

Deployed · open sourceRust · Axum · PostgreSQL · SQLx · React

Feature Flag Service as it appears in a browser — ffs.adarshrust.com

Feature flags separate deploying code from releasing it. The hosted services that do this are priced per seat and want your evaluation traffic; the self-hosted options are mostly heavy. This is a small one you can run yourself.

Two APIs sit on the same Postgres schema: a management API behind JWT auth for creating projects, environments, flags and targeting rules, and an SDK endpoint behind a project key that evaluates every flag for one user in a single request.

What I built

The whole backend: Axum handlers, the Postgres schema and migrations, the evaluation engine, and the auth layer.
The React dashboard that drives the management API, and the service's own deployment.

Decisions worth defending

Rollouts hash instead of sampling: A percentage rollout decides per user with an FNV-1a hash of the user key, so the same user keeps the same answer across calls and across processes. Sampling at random would flicker the feature on and off for the same person.
Evaluation is one request, not one per flag: The SDK endpoint returns every flag for a user in one response. Flags are checked in a fixed order — global kill switch, then targeting rules by priority, then the rollout bucket — so the result is explainable.
Logging the evaluation does not block the answer: Every evaluation is recorded for the analytics view, but the write is detached from the response path. The flag answer is on the hot path; the audit trail is not.
Auth that assumes the service is exposed: Argon2 password hashing, JWTs for the dashboard, separate SDK keys for clients, IP rate limiting on the auth and SDK routes, and user-scoped queries so a project is only reachable by its owner.

Open ffs.adarshrust.com (opens in a new tab)Read the source (opens in a new tab)

OSSPath

A map of the Rust ecosystem, built from what real projects actually depend on.

Deployed · open sourceTypeScript · Next.js · PostgreSQL · Prisma · Cloudflare

OSSPath as it appears in a browser — osspath.com

Crate documentation tells you what a library claims to do. OSSPath starts from the other end: it reads the Cargo manifests of thousands of production Rust repositories and reports what people actually depend on, what those crates get used alongside, and which companies ship them.

That turns into a route for someone trying to get hired in Rust — pick backend, systems, infrastructure or embedded, and the site names the crates that matter for it and the real repositories where you can read them in use.

5,607
Rust repositories indexedas published on the site: 0
database queries per page view

What I built

The ingestion pipeline that collects repositories and resolves their dependency graphs into Postgres.
The publishing step, the prerendered public site, and the admin panel that reviews content before it goes live.

Decisions worth defending

The public site has no database: Publishing exports the whole corpus to JSON, commits it, and triggers a build that prerenders every page. Visitors hit static files on a CDN. Nothing public can be slowed down or taken out by the database, and a bad snapshot is a git revert.
Numbers carry the date they were computed: Every figure on the site is rendered from the published snapshot and shown with the date it was verified, because a stale number presented as live is worse than no number.
Nothing appears unreviewed: The pipeline proposes; the admin panel approves. Repositories, jobs and resources are reviewed before they can be published.

Open osspath.com (opens in a new tab)Read the source (opens in a new tab)

LoopUpward

A personal planning system where progress on small things rolls up into the large ones.

Deployed · open sourceRust · TypeScript · PostgreSQL · Docker

LoopUpward as it appears in a browser — loopupward.com

Most planning tools start at the task. People do not — they start at "I want to learn this" and never get to the task. LoopUpward keeps goals, habits, routines and notes as one kind of object that can nest inside another, so a chapter read today can sit under a book, under a course, under a year.

The interesting part is the arithmetic. An item with its own tracker reports its own progress; one without averages its children. Completing something nested inside a metered parent ticks that parent, and the tick climbs the whole chain, with every move written to history.

What I built

The data model where every item is the same object with a kind, and any item can parent any other.
The rollup rules — progress averaging upward, completion cascading upward, and both recorded as history entries rather than recomputed.
The Rust service behind it and the scheduling that places repeating items on their days.

Decisions worth defending

One object, many kinds: A goal, habit, routine, book and note are the same row with a different kind, so an item can change what it is without migrating anything, and nesting works between any two kinds.
Progress is written, not derived: Each rollup writes a history entry instead of being recomputed from children on read. The number you saw last week stays the number you saw last week.
Days have edges that match the user, not UTC: A routine finished at 12:30am is attributed to the evening it started, up to a 4am cutoff, because otherwise a night routine breaks its streak by being finished.

Open loopupward.com (opens in a new tab)Read the source (opens in a new tab)

Romyq

A terminal tool that keeps a long AI-assisted coding session pointed at the original goal.

Released · open source · Python, not RustPython · Local-first

Romyq as it appears in a browser — romyq.com

Coding agents hold a plan for minutes and lose it over hours. Left running on a long task they drift — skipping validation, forgetting constraints, and reporting success early.

Romyq puts a lifecycle around the session: a written mission, ordered phases, governance rules every task is checked against, and readiness tracking that has to be satisfied before a phase closes. All state is files in .romyq/ in the project. No cloud, no telemetry.

What I built

The lifecycle engine — phases, governance rules, readiness gates and the project memory that survives between sessions.
The terminal interface, and distribution through PyPI and a Homebrew tap.

Decisions worth defending

State is files in the repository: Everything lives in .romyq/ next to the code it describes, so it diffs, reviews and branches like the rest of the project. There is no server to be the source of truth.
Planning and execution are separate providers: The thing that decides what to do next and the thing that writes code are different, swappable roles, so a cheaper or local model can do one of them.

Open romyq.com (opens in a new tab)Read the source (opens in a new tab)

Adarsh