Introducing Automatic Documentation Generation for Environment Variables

How many hours has your team spent updating README files that are already outdated? Documentation drift costs teams 2-3 hours per week. Time that could build features instead of maintaining docs that are already wrong.

Every team faces the same challenge: keeping env var docs up to date. You've probably seen (or written) docs like this:

Copy
## Environment Variables

- DATABASE_URL: Your database connection string
- API_KEY: Get this from the settings page
- DEBUG: Set to true for development
- PORT: Server port (default: 3000)

This approach fails. Docs drift. Context is missing. Info is scattered. Onboarding's painful. Security risks go unnoticed. But what if your docs could stay current automatically? Generated directly from your source of truth?

We're excited to announce: automatic documentation generation for environment variables. One command, env-sentinel generates comprehensive, structured markdown docs from your annotated schema files. Your docs stay accurate. Current. Useful.

Table of Contents

• The Problem with Environment Variable Documentation
• Why Use Automatic Documentation Generation?
• What Is Automatic Documentation Generation?
• How Automatic Documentation Generation Works
• Key Features and Benefits
• Comparison: Manual vs Automatic Documentation
• Step-by-Step Guide: Getting Started
• Real-World Use Cases and Examples
• Advanced Features and Customization
• Integration with CI/CD Pipelines
• Troubleshooting Common Issues
• Best Practices for Documentation Generation
• Frequently Asked Questions
• Conclusion: Documentation That Stays Current

The Problem with Environment Variable Documentation

Every team faces the same challenge: keeping env var docs up to date. You've probably seen (or written) docs like this:

Copy
## Environment Variables

- DATABASE_URL: Your database connection string
- API_KEY: Get this from the settings page
- DEBUG: Set to true for development
- PORT: Server port (default: 3000)

This approach fails because:

• Documentation drifts - README files get outdated as variables change. Someone adds a new variable, forgets to update docs. Six months later? Wrong.
• Missing context - No info about types, constraints, validation rules. Devs don't know if PORT should be a number or string, valid range, or if it's required.
• Scattered information - Comments in code, wiki pages, Slack messages, tribal knowledge. New devs spend hours hunting for info that should be in one place.
• Onboarding friction - New devs spend hours figuring out config. They ask in Slack, dig through old PRs, interrupt senior devs.
• Security risks - Unclear which variables are sensitive. Secrets aren't clearly marked, leading to accidental exposure in logs or commits.

⚠️ The Real Cost: Documentation drift isn't just annoying—it's expensive. Teams waste 2-3 hours per week maintaining outdated docs. Onboarding new devs takes 2-3 days longer when docs are incomplete or wrong.

This is why undocumented env vars are one of the most common mistakes teams make. Solution? Generate docs automatically from schema files. They never go out of date.

Why Use Automatic Documentation Generation?

Before diving into how it works, let's understand why it matters. Benefits go way beyond convenience.

Time Savings

Manual Documentation:

• Write docs when adding variables
• Update docs when variables change
• Review docs in code reviews
• Fix docs when they drift
• Total: 2-3 hours per week per team

Automatic Documentation:

• Annotate schema once (30 seconds)
• Docs generate automatically
• Always stays synchronized with schema
• Total: 5 minutes per week per team

💡 Pro Tip: Time savings compound as your team grows. With 10 devs, automatic docs save 20-30 hours per week. That's a full-time employee's worth of productivity.

Accuracy and Consistency

Manual docs inevitably drift. Someone adds a variable, forgets to update README. Someone changes a default value, doesn't update docs. Someone removes a variable, leaves it in docs.

Automatic docs eliminate drift. Generated directly from your schema—the source of truth. Schema correct? Docs correct. Always.

Better Developer Experience

New devs can understand your entire config by reading one auto-generated file. No more hunting through README files, wiki pages, asking senior devs what each variable does. Docs are comprehensive. Organized. Always current.

Security Benefits

Automatic docs clearly mark sensitive variables with security indicators (🔒). Makes security audits easier. Quickly identify all credentials that need rotation, encryption, special handling.

ROI Calculation

Let's do the math:

• Team size: 10 devs
• Time saved: 2 hours per week per dev
• Hourly rate: $100/hour
• Weekly savings: 20 hours × $100 = $2,000/week
• Annual savings: $104,000/year

ROI is clear: automatic docs pay for themselves many times over.

What Is Automatic Documentation Generation?

Automatic documentation generation creates comprehensive docs directly from your source code or config files—in this case, from your env var schema files.

Instead of manually writing and maintaining docs, you:

1. Annotate your schema with special comment tags
2. Run a command to generate docs
3. Get comprehensive docs always synchronized with your schema

Generated docs include:

• Table of contents for easy navigation
• Organized sections grouped by purpose
• Complete info (type, constraints, defaults, descriptions)
• Security highlights for sensitive variables
• Example values for each variable
• Always current (generated from schema, never outdated)

This follows the DRY principle—define your config once in the schema, docs generate automatically.

How Automatic Documentation Generation Works

Process is simple: annotate your schema, run a command, get beautiful docs. Let's walk through it.

Step 1: Annotate Your Schema

Add special comment tags to your .env-sentinel schema file:

Copy
# ============================================================================
# @section Database
# @description Database connection and configuration settings.
# All database-related variables including connection pooling.
# Make sure to use secure passwords and proper SSL configuration in production.
# ============================================================================

# @var Database server hostname or IP address
# @example localhost
DB_HOST=required

# @var Database server port number
# @example 5432
DB_PORT=required|number|min:1|max:65535

# @var Database password (keep secure!)
DB_PASSWORD=required|secure|min:8

The annotation format is simple:

• @section - Defines a section name
• @description - Describes the section (supports multiple lines)
• @var - Describes a variable (supports multiple lines)
• @example - Provides an example value

Step 2: Generate Documentation

Run the docs command:

Copy
npx env-sentinel docs

Or specify custom paths:

Copy
npx env-sentinel docs --schema .env-sentinel --output docs/CONFIG.md

Step 3: Get Beautiful Documentation

Generated docs are clean. Organized. Easy to navigate. Here's what your team will see:

Database

Database connection and configuration settings. All database-related variables including connection pooling. Make sure to use secure passwords and proper SSL configuration in production.

Each section is clearly organized with descriptions, constraints, security indicators. Docs are ready to commit and share with your team.

Key Features and Benefits

Automatic docs come with powerful features that make them superior to manual docs.

Smart Type Extraction

The docs generator automatically extracts type info from your validation rules:

• number validator → Type: number
• boolean validator → Type: boolean
• enum validator → Type: enum with allowed values
• No type specified → Type: string (default)

You don't need to manually document types—they're inferred from validation rules.

Automatic Constraint Documentation

Constraints are automatically extracted and formatted:

Copy
APP_PORT=number|min:1|max:65535

Becomes:

No manual formatting needed. Constraints documented automatically.

Security Highlighting

Variables with the secure validator are automatically marked with a 🔒 icon. Makes it clear which values need special protection:

Copy
JWT_SECRET=required|secure|min:32
API_KEY=required|secure

Makes security audits easier—quickly scan docs to find all sensitive variables.

Multi-line Descriptions

Section descriptions and variable descriptions support multiple lines for detailed explanations:

Copy
# @var Secret key for JWT token signing (keep secure!).
# Must be at least 32 characters long with high entropy.
# Never commit this value to version control.
JWT_SECRET=required|secure|min:32

Provides comprehensive context without cluttering your schema file.

Table of Contents

For schemas with multiple sections, a table of contents is automatically generated with anchor links:

Copy
## Table of Contents

- [Application](#application)
- [Database](#database)
- [Cache](#cache)
- [Security](#security)

This makes navigation easy, especially for large schemas with many variables.

Always Current

Biggest benefit? Your docs are always synchronized with your schema. Update your schema, regenerate docs—instantly updated. No more drift. No more outdated info.

Comparison: Manual vs Automatic Documentation

Let's compare manual and automatic docs to understand the differences:

The Verdict: Manual docs have a lower initial barrier. But automatic docs save significant time and ensure accuracy. Initial investment in annotating your schema pays off fast—reduced maintenance, improved accuracy.

Before and After Example

Before (Manual Documentation):

Copy
## Environment Variables

- DATABASE_URL: Database connection string
- API_KEY: API key for external service
- PORT: Server port

Problems:

• Missing type information
• No constraints documented
• No examples
• No security indicators
• Will drift over time

After (Automatic Documentation):

Copy
## Database

Database connection and configuration settings.

| Variable | Description | Type | Required | Default | Constraints |
|----------|-------------|------|----------|---------|-------------|
| `DATABASE_URL` | PostgreSQL connection URL | `string` | Yes | - | - |
| 🔒 `API_KEY` | External service API key | `string` | Yes | - | Min: 32 characters |

**Example:**
```bash
DATABASE_URL=postgresql://user:pass@localhost:5432/mydb
API_KEY=sk_live_abc123def456...

**Benefits:**
- Complete type information
- Constraints documented
- Examples provided
- Security indicators
- Always synchronized with schema

## Step-by-Step Guide: Getting Started

Ready to get started? Here's a complete guide from zero to generating your first docs.

### Step 1: Install env-sentinel

If you haven't already, install <Keyword>env-sentinel</Keyword>:

<TabbedCodeBlock
  tabs={[
    {
      label: 'npm',
      content: 'npm install --save-dev env-sentinel'
    },
    {
      label: 'yarn',
      content: 'yarn add --dev env-sentinel'
    },
    {
      label: 'pnpm',
      content: 'pnpm add -D env-sentinel'
    }
  ]}
/>

Or use it directly with npx (no installation):

```bash
npx env-sentinel docs

Step 2: Create or Update Your Schema

Don't have a schema file yet? Create one:

Copy
npx env-sentinel init

This analyzes your existing .env file and creates a basic schema. Then add annotations:

Copy
# @section Application
# @description Core application settings and behavior

# @var Application name displayed in logs and UI
# @example MyAwesomeApp
APP_NAME=required

# @var Server port number
# Range: 1-65535
# @example 3000
APP_PORT=number|min:1|max:65535|default:"3000"

Step 3: Add Documentation Annotations

Add @section, @description, @var, and @example tags to your schema:

Copy
# @section Database
# @description PostgreSQL database connection settings

# @var Database connection URL
# Format: postgresql://user:password@host:port/database
# @example postgresql://admin:secret@localhost:5432/myapp
DATABASE_URL=required

# @var Maximum database connection pool size
# Keep this under 100 to prevent database overload
# @example 10
DB_POOL_MAX=number|min:1|max:100|default:"10"

Step 4: Generate Documentation

Run the docs command:

Copy
npx env-sentinel docs

This generates CONFIGURATION.md in your current directory. Custom output path:

Copy
npx env-sentinel docs --output docs/ENVIRONMENT.md

Step 5: Review and Commit

Review the generated docs:

Copy
cat CONFIGURATION.md

Looks good? Commit it:

Copy
git add CONFIGURATION.md
git commit -m "docs: add auto-generated environment variable documentation"

Step 6: Set Up CI/CD (Optional)

To keep docs automatically updated, add to your CI/CD pipeline (see Integration with CI/CD Pipelines section below).

That's it! Your docs are now automatically generated and always synchronized with your schema.

Real-World Use Cases and Examples

Let's explore real-world scenarios where automatic docs make a difference.

Use Case 1: Team Onboarding

Scenario: New dev joins your team. They need to understand your app's configuration.

Without Automatic Docs:

1. Read README.md (outdated)
2. Check wiki pages (incomplete)
3. Ask in Slack (interrupts team)
4. Dig through old PRs (time-consuming)
5. Total time: 2-3 hours

With Automatic Docs:

1. Read CONFIGURATION.md (comprehensive, current)
2. Total time: 15 minutes

New devs can quickly understand your entire config by reading one file:

Copy
# Clone repo
git clone your-repo
cd your-repo

# Read configuration docs
cat CONFIGURATION.md

No more hunting through README files, wiki pages, asking senior devs what each variable does.

Use Case 2: CI/CD Integration

Scenario: You want docs to stay automatically updated when schemas change.

Solution: Add docs generation to your CI/CD pipeline:

Copy
# GitHub Actions
name: Generate Documentation

on:
  push:
    paths:
      - '.env-sentinel'
      - '.env-sentinel.*'

jobs:
  generate-docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Generate environment docs
        run: npx env-sentinel docs
        
      - name: Commit documentation
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: "docs: update environment variables [skip ci]"
          file_pattern: CONFIGURATION.md

Every schema change automatically updates your docs. No manual steps required.

Use Case 3: Security Audits

Scenario: You need to identify all sensitive variables for a security audit.

Solution: Generate docs and search for security indicators:

Copy
# Generate docs
npx env-sentinel docs

# Find all secure variables
grep "🔒" CONFIGURATION.md

Instant overview of all credentials that need rotation, encryption, special handling. Especially useful when combined with proper env var management practices.

Use Case 4: Configuration Reviews

Scenario: Before deploying to production, you want to review all required variables.

Solution: Generate docs from your production schema:

Copy
# Generate docs from production schema
npx env-sentinel docs --schema .env-sentinel-production --output prod-config.md

# Review all required variables
grep "Yes" prod-config.md | grep "Required"

Catch missing or misconfigured variables before they cause outages. Complements early validation strategies for comprehensive config management.

Use Case 5: Multi-Environment Documentation

Scenario: You have different schemas for dev, staging, and production.

Solution: Generate separate docs for each environment:

Copy
# Development
npx env-sentinel docs --schema .env-sentinel.development --output docs/DEV.md

# Staging
npx env-sentinel docs --schema .env-sentinel.staging --output docs/STAGING.md

# Production
npx env-sentinel docs --schema .env-sentinel.production --output docs/PROD.md

Each environment gets its own comprehensive docs. Easy to understand differences between environments.

Advanced Features and Customization

Beyond basic docs generation, env-sentinel offers advanced features for customization and integration.

Custom Output Formats

While markdown is the default, you can customize the output:

Copy
# Generate to specific directory
npx env-sentinel docs --output docs/configuration.md

# Generate for specific environment
npx env-sentinel docs --schema .env-sentinel.production --output docs/prod-config.md

Schema Organization

Organize large schemas into logical sections:

Copy
# @section Application
# @description Core application settings

# @section Database
# @description Database connection and configuration

# @section External Services
# @description Third-party API integrations

# @section Security
# @description Security and authentication settings

The generated documentation maintains this organization with clear section headers and table of contents.

Rich Annotations

Use multi-line descriptions for comprehensive documentation:

Copy
# @var JWT signing secret
# This secret is used to sign and verify JWT tokens.
# Must be at least 32 characters long with high entropy.
# Rotate this secret monthly for security.
# Never commit this value to version control.
# @example sk_live_abc123def456ghi789jkl012mno345pqr678stu901vwx234yz
JWT_SECRET=required|secure|min:32

Generated docs preserve all this context. Makes it easy for devs to understand not just what a variable is, but why it exists and how to use it.

Integration with Validation

Docs generation works seamlessly with validation. When you validate your environment:

Copy
npx env-sentinel validate

Same schema that validates your config also generates your docs. Ensures docs and validation rules are always synchronized.

Integration with CI/CD Pipelines

Keeping docs automatically updated is crucial. Here's how to integrate docs generation into your CI/CD pipeline.

GitHub Actions

Copy
name: Auto-Generate Documentation

on:
  push:
    branches: [main]
    paths:
      - '.env-sentinel'
      - '.env-sentinel.*'

jobs:
  docs:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
      
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      
      - name: Generate documentation
        run: npx env-sentinel docs
      
      - name: Commit documentation
        uses: stefanzweifel/git-auto-commit-action@v4
        with:
          commit_message: "docs: auto-update environment variable documentation"
          file_pattern: CONFIGURATION.md
          skip_dirty_check: true

GitLab CI/CD

Copy
generate-docs:
  image: node:18
  script:
    - npx env-sentinel docs
    - |
      if [ -n "$(git status --porcelain CONFIGURATION.md)" ]; then
        git config user.name "GitLab CI"
        git config user.email "ci@gitlab.com"
        git add CONFIGURATION.md
        git commit -m "docs: auto-update environment variable documentation"
        git push
      fi
  only:
    changes:
      - .env-sentinel
      - .env-sentinel.*

Pre-commit Hook

Generate documentation before every commit:

Copy
#!/bin/bash
# .git/hooks/pre-commit

# Generate documentation
npx env-sentinel docs

# Stage the generated file
git add CONFIGURATION.md

This ensures docs are always up to date before commits.

Troubleshooting Common Issues

Even with automatic docs, you might hit issues. Here's how to troubleshoot common problems.

Issue 1: Documentation Not Generating

Symptoms: Running npx env-sentinel docs produces no output or errors.

Solutions:

1. Check schema file exists:

   Copy
   ls -la .env-sentinel
   

2. Verify schema syntax:

   Copy
   npx env-sentinel validate
   

3. Check for annotation syntax errors:

   • Ensure @section tags are properly formatted
   • Verify @var comments are on lines before variables
   • Check for typos in annotation tags

Issue 2: Missing Sections in Documentation

Symptoms: Some sections don't appear in generated docs.

Solutions:

1. Check section annotations:

   Copy
   # @section Database  # Must be before variables in section
   

2. Verify section names:

   • Section names are case-sensitive
   • Use consistent naming throughout schema

3. Check for duplicate sections:

   • Each section should be unique
   • Variables belong to the most recent @section tag

Issue 3: Variables Missing Descriptions

Symptoms: Some variables appear without descriptions in docs.

Solutions:

1. Add @var comments:

   Copy
   # @var Description of what this variable does
   VARIABLE_NAME=required
   

2. Check comment placement:

   • @var comments must be immediately before the variable
   • No blank lines between comment and variable

Issue 4: Security Indicators Not Showing

Symptoms: Variables marked with secure don't show 🔒 icon.

Solutions:

1. Verify secure validator:

   Copy
   SECRET_KEY=required|secure
   

2. Check validator syntax:

   • Use secure (lowercase)
   • Place after required if both are used

Issue 5: CI/CD Integration Not Working

Symptoms: Docs don't update automatically in CI/CD.

Solutions:

1. Check file paths:

   • Ensure schema file path is correct in CI/CD config
   • Verify output path is writable

2. Verify Git permissions:

   • CI/CD needs write access to commit documentation
   • Check token permissions in GitHub/GitLab settings

3. Check trigger paths:

   • Ensure CI/CD triggers on schema file changes
   • Verify path patterns match your schema files

Quick Debugging Checklist

When troubleshooting documentation generation:

• Schema file exists and is readable
• Schema syntax is valid (run validate command)
• Annotation tags are correctly formatted
• Section annotations are present
• Variable descriptions are added
• Output directory is writable
• CI/CD permissions are correct

Best Practices for Documentation Generation

To get the most out of automatic docs generation, follow these best practices.

1. Document as You Build

💡 Pro Tip: Add @var comments when you first create variables, not as an afterthought. This ensures documentation is always current.

Don't wait until the end to document. Add annotations as you add variables:

Copy
# @var Database connection URL
# Format: postgresql://user:password@host:port/database
DATABASE_URL=required

This creates a habit of documentation and ensures nothing is forgotten.

2. Use Sections Wisely

Group related variables into logical sections:

Copy
# @section Database
# @description Database connection and configuration

# @section Cache
# @description Caching configuration

# @section Email
# @description Email service configuration

# @section Security
# @description Security and authentication settings

This makes generated documentation easier to navigate, especially for large schemas.

3. Provide Meaningful Examples

Use realistic example values that help developers understand the expected format:

Copy
# @example postgresql://user:pass@localhost:5432/mydb
DATABASE_URL=required

Avoid placeholder values like "your_value_here"—use real examples that show the format.

4. Explain Constraints

When using min, max, or enum, explain why these constraints exist:

Copy
# @var Maximum concurrent database connections
# Keep this under 100 to prevent database overload.
# Higher values can cause connection pool exhaustion.
# @example 10
DB_POOL_MAX=number|min:1|max:100|default:"10"

This helps developers understand not just what the constraint is, but why it exists.

5. Mark Security-Critical Variables

Always use the secure validator for sensitive data:

Copy
# @var JWT signing secret (rotate monthly)
# This secret is used to sign authentication tokens.
# Must be at least 32 characters with high entropy.
JWT_SECRET=required|secure|min:32

These appear with 🔒 in documentation, making security reviews easier.

6. Keep Descriptions Concise but Complete

Balance brevity with completeness:

Copy
# Good: Concise but complete
# @var Stripe secret key for payment processing
# Get this from https://dashboard.stripe.com/apikeys
STRIPE_SECRET_KEY=required|secure

# Bad: Too brief
# @var Stripe key
STRIPE_SECRET_KEY=required|secure

# Bad: Too verbose
# @var This is the Stripe secret key that you need to get from the Stripe dashboard
# which is located at https://dashboard.stripe.com and then you go to the API keys section
# and copy the secret key from there
STRIPE_SECRET_KEY=required|secure

7. Review Generated Documentation

Before committing, review the generated docs:

Copy
npx env-sentinel docs
cat CONFIGURATION.md

Make sure it looks good and contains all necessary info. Adjust annotations if needed.

8. Version Control Generated Docs

Commit generated docs to your repository:

Copy
git add CONFIGURATION.md
git commit -m "docs: update environment variable documentation"

Makes docs accessible to all team members and searchable in your repository.

Frequently Asked Questions

What is automatic documentation generation?

Automatic docs generation creates comprehensive docs directly from your source code or config files—in this case, from your env var schema files. Instead of manually writing and maintaining docs, you annotate your schema with special comment tags, run a command, get comprehensive docs always synchronized with your schema.

How does automatic documentation generation work?

Process is simple:

1. Annotate your schema with @section, @description, @var, and @example tags
2. Run the command npx env-sentinel docs
3. Get comprehensive docs in markdown format

The docs generator reads your annotated schema and creates formatted markdown docs with tables, descriptions, examples, security indicators.

Why should I use automatic documentation instead of manual?

Automatic docs offer several advantages:

• Always current - Generated from schema, never drifts
• Time savings - 2-3 hours per week vs 5 minutes per week
• Accuracy - No typos or missing info
• Consistency - Same format every time
• Completeness - All variables documented automatically
• Security - Automatic security indicators

For more on benefits, see our comparison section.

What file formats does it support?

Currently, env-sentinel generates markdown (.md) docs. Format is compatible with GitHub, GitLab, most docs platforms. Future versions will support JSON and HTML output formats.

Can I customize the generated documentation?

Yes! You can customize:

• Output path - Specify where docs are generated
• Section organization - Organize variables into logical sections
• Descriptions - Add detailed multi-line descriptions
• Examples - Provide example values for each variable

Docs format itself (markdown tables) is standardized for consistency, but you control the content through schema annotations.

How do I integrate it into my CI/CD pipeline?

Add docs generation to your CI/CD pipeline. See the Integration with CI/CD Pipelines section for complete examples for GitHub Actions, GitLab CI/CD, pre-commit hooks.

Key is to:

1. Generate docs when schema files change
2. Commit generated docs automatically
3. Ensure CI/CD has write permissions

Does it work with existing documentation?

Yes! You can migrate from manual docs gradually:

1. Keep existing docs temporarily
2. Generate automatic docs alongside it
3. Compare and verify accuracy
4. Replace manual docs once confident

Many teams run both in parallel during migration to ensure nothing is lost.

What happens if my schema changes?

Simply regenerate the docs:

Copy
npx env-sentinel docs

New docs will reflect all schema changes automatically. Have CI/CD integration? This happens automatically when you commit schema changes.

Can I generate documentation for multiple environments?

Yes! Generate separate docs for each environment:

Copy
# Development
npx env-sentinel docs --schema .env-sentinel.development --output docs/DEV.md

# Staging
npx env-sentinel docs --schema .env-sentinel.staging --output docs/STAGING.md

# Production
npx env-sentinel docs --schema .env-sentinel.production --output docs/PROD.md

Each environment gets its own comprehensive docs.

How do I migrate from manual documentation?

Migration is straightforward:

1. Create or update your schema - Add annotations to existing schema or create new one
2. Generate docs - Run npx env-sentinel docs
3. Review generated docs - Compare with existing docs
4. Update references - Point team to new docs location
5. Remove old docs - Delete outdated manual docs

For teams with common docs mistakes, this migration eliminates those issues permanently.

Conclusion: Documentation That Stays Current

Automatic docs generation transforms how teams manage env var docs. Instead of spending hours maintaining outdated README files, you generate comprehensive, always-current docs with one command.

Key Benefits:

• Time savings - 2-3 hours per week becomes 5 minutes per week
• Accuracy - Docs never drift from your schema
• Better onboarding - New devs understand config quickly
• Security - Clear indicators for sensitive variables
• Consistency - Same format every time

Next Steps:

1. Install env-sentinel (or use npx)
2. Annotate your schema with docs tags
3. Generate your first docs
4. Set up CI/CD integration for automatic updates
5. Share with your team

Docs generation feature is available now in env-sentinel v1.4.0. We're excited to see how teams use it to improve their config workflows.

Coming Soon

We're working on additional docs features:

• JSON output format - For programmatic consumption
• HTML documentation - With search and filtering
• Diff detection - Show what changed between schema versions
• Documentation validation - Ensure all variables are documented

Try It Today

Ready to improve your env var docs?

Copy
# Try it with npx (no installation required)
npx env-sentinel@latest docs --help

# Or install and use
npm install --save-dev env-sentinel
npx env-sentinel docs

Check out the full docs at envsentinel.dev/docs/documenting for detailed guides, examples, best practices.

Feedback Welcome

We'd love to hear how you're using the docs feature! Share your feedback:

• 🐛 Report issues on GitHub
• ⭐ Star us on GitHub

With automatic docs generation, your team can spend less time explaining config and more time building features. Happy documenting! 🚀