A tiny Rust CLI that authenticates with GitLab, prepares SSH keys, standardizes Git config, and wires up npm & Docker so new devs can clone, push, and publish without a live walkthrough.

TL;DR

  • Problem: Constant onboarding churn and limited DevOps time made teaching Git/GitLab repeatedly a bottleneck.
  • Solution: A Rust CLI that automates GitLab auth (OAuth/PAT), SSH key generation & upload, Git config, npm & Docker registry login, plus a doctor check.
  • Why Rust: type safety, performance, cross‑platform binaries (Linux/macOS/Windows), and a great fit for robust CLI tooling.
  • Outcome: Interns ship code faster; setups are uniform; I spend time on higher‑leverage work instead of repeating the same steps.

The Real-World Constraint

Our company hires a many interns. I love mentoring but I’m also the solo DevOps engineer with a long to‑do list. Re‑explaining Git remotes, SSH keys, token scopes, and npm registry auth every week wasn’t sustainable.

I needed something that removes friction, enforces consistency, and scales my time. Enter a single command that boots a machine from “fresh laptop” to “ready to push & publish”.

Design Principles

  1. Safety first: Rust’s type system and strong error handling reduce runtime surprises. I want dependable onboarding flows.
  2. Fast and portable: Compiled binaries with zero runtime deps = instant startup and easy distribution.
  3. Cross‑platform: One codebase; release Linux/macOS/Windows binaries. Interns use whatever OS they prefer.
  4. Least surprise: Opinionated defaults (Git settings, token scopes, registry URLs) that match our org’s policy.
  5. Idempotent: Re‑running the tool should fix drift, not duplicate keys or configs.
  6. Testable: HTTP/API code is unit‑ and integration‑testable; config is versioned and round‑trips cleanly.

High-Level Architecture

  • CLI surface (Clap): clear subcommands: init, auth (oauth|pat), ssh (generate|upload), git config, npm setup, docker login, doctor, update.
  • GitLab Auth:
    • OAuth 2.0 with PKCE for user-friendly browser login (local callback server, secure state).
    • PAT management (create/list/revoke) for automated or headless flows.
  • Config & Storage: versioned config file under the OS‑correct app directory (so paths are right on Linux/macOS/Windows).
  • HTTP Client: shared client with automatic Authorization headers (no token leaks to logs).
  • Local Tooling: runs shell‑safe commands only when needed (e.g., git presence, ssh-keygen if missing).

A typical “happy path” looks like this:

dev-bootstrap init
dev-bootstrap auth oauth
dev-bootstrap ssh generate
dev-bootstrap ssh upload
dev-bootstrap git config
dev-bootstrap npm setup
dev-bootstrap docker login
dev-bootstrap doctor

Finish: clone → push → publish with no manual token dances.

Why Rust for a DevOnboarding CLI

Safety & Reliability

Rust’s type safety and ownership model push a whole class of bugs to compile time. That matters when your tool touches credentials, keys, and developer environments. I want predictable behavior and clear failures.

Performance & UX

CLIs should feel instant. Rust binaries start fast, parse flags quickly, and run network flows without overhead. That smoothness becomes perceived quality for new devs.

Cross‑Platform Binaries

Shipping signed binaries for Linux, macOS, and Windows means fewer “it works on my machine” moments. The configuration layer picks the right paths and file locations per OS so everything lands where users (and the OS) expect it.

Subcommands (What the Tool Does)

  • init friendly wizard that asks for name/email once, then chains the rest of the steps.
  • auth oauth opens the browser, uses PKCE, exchanges code for tokens, saves them to config (with expiry).
  • auth pat non‑interactive or headless machines; manage Personal Access Tokens with proper scopes.
  • ssh generate creates an ed25519 keypair if missing; prints safe file permissions.
  • ssh upload calls GitLab’s /user/keys API with a consistent key title (hostname + username).
  • git config sets user.name, user.email, sane defaults (init.defaultBranch=main, pull.ff=only, push.default=current).
  • npm setup writes .npmrc with our GitLab registry URL and token plumbing.
  • docker login authenticates to the GitLab container registry with PAT scopes (read_registry/write_registry).
  • doctor checks versions and reachability for git, ssh, node/npm, docker, and GitLab; prints a one‑screen pass/fail report with fixes.

Each command is idempotent: rerun without fear.

Security Posture

  • PKCE + state in OAuth to prevent token interception.
  • Scoped tokens only; PAT creation defaults to least privilege.
  • Sensitive logs redacted; tokens never echoed.
  • Config versioning for painless upgrades as the tool evolves.

Developer Experience & Org Impact

  • Time to First Push (TTFP) collapses to minutes.
  • Uniform setups across interns: same Git settings, same SSH key standards, same registry auth.
  • Lower support load: fewer tickets about “permission denied (publickey)”, missing npm scopes, or wrong remotes.
  • Teachable moments preserved: I still encourage learning Git fundamentals but the tool removes friction and mistakes on day one.

Example Snippets

OAuth callback (conceptual)

// start a tiny local server to catch the authorization code, then exchange it
let (code, state) = oauth::await_callback("http://localhost:53123/oauth/callback")?;
let token = oauth::exchange_code_for_token(code, state)?;
config.store_token(token)?;

SSH upload

// read public key, post to GitLab under a predictable title
let pubkey = std::fs::read_to_string("~/.ssh/id_ed25519.pub")?;
api.gitlab_add_ssh_key(format!("{} ({})", hostname(), username()), pubkey).await?;

Doctor checklist (sketch)

[✔] git 2.46+       [✔] ssh
[✔] node 20+        [✔] npm
[✔] docker          [✔] GitLab reachable
[✔] PAT/OAuth token valid (expires 2026-01-03)

Rollout Plan (Small, Safe Steps)

  1. Pilot with a handful of interns; gather OS coverage (Win/macOS/Linux).
  2. Bake into onboarding: “download binary → run init → push your first branch.”
  3. Add telemetry (optional): anonymous TTFP metric to see the impact.
  4. Publish signed releases in GitLab Releases with checksums; add --version to binary.

What You Can Copy

  • Treat onboarding as software, not a slide deck.
  • Choose Rust for robust, cross‑platform CLI tooling.
  • Make flows idempotent and testable.
  • Prefer PKCE OAuth; fall back to PATs only when needed.
  • Provide a doctor command; your future self will thank you.

Closing

The best developer experience is the one that gets out of the way. A small, safe, cross‑platform Rust CLI turns Git/GitLab onboarding into a one‑command ritual so new teammates can push code, and I can focus on the rest of the platform.

Keywords: Rust CLI, GitLab OAuth, Git onboarding, DevEx, cross‑platform binaries, developer productivity, PKCE, SSH keys, npm registry, Docker registry