Free Tool

ADR Generator

Create Architecture Decision Records with a structured form. Preview as Markdown, export as PDF. Follow the standard ADR template used by engineering teams.

Example ADR

A backend team decides how to handle API authentication for a new microservice.

ADR-003: Use JWT for service-to-service authentication

Date: 2026-03-15 Status: Accepted Deciders: Backend team, Security lead

Context

Our new order service needs to authenticate requests from four internal services. The current approach uses shared API keys stored in environment variables. As the number of services grows, managing and rotating shared keys becomes error-prone and hard to audit.

Decision

We will use short-lived JWTs signed with RS256 for service-to-service authentication. Each service gets its own key pair. Tokens expire after 5 minutes.

Consequences

Positive

  • No shared secrets to rotate across services
  • Token expiry limits the damage window if a token leaks
  • Standard JWT libraries available in all our languages

Negative

  • Adds complexity: each service needs key management
  • Clock skew between services can cause false rejections
  • Team needs to learn JWT validation and key rotation

Need to decide with your team?

DecTrack helps teams make structured, transparent decisions together, from defining options to reaching consensus.

Frequently Asked Questions

An ADR is a short document that captures a single architecture decision. It records the context, the decision itself, and its consequences so future team members understand why the codebase looks the way it does.
This tool follows the widely adopted template by Michael Nygard: Title, Status, Context, Decision, and Consequences. It is the same format used by most open-source projects and engineering organizations.
Write an ADR whenever you make a technical decision that is hard to reverse or affects other team members. Examples: choosing a database, adopting a framework, changing an API design pattern, or selecting a deployment strategy.
Best practice is to store ADRs in your code repository, typically in a docs/adr/ or doc/architecture/decisions/ folder. This keeps decisions close to the code they describe and makes them part of code review.
An ADR focuses on technical and architecture decisions and follows a specific template (Context, Decision, Consequences). A Decision Log is broader and covers any team decision (hiring, vendors, processes). Both serve the same goal: preserving decision context for the future.
Yes. You can copy the Markdown output directly or export a branded PDF. The Markdown is ready to paste into your repository.