Home Original page

Getting Started

Erode detects architecture drift by comparing code changes against your architecture model. When a change introduces an undeclared dependency, Erode surfaces it as a finding and comments directly on the code change.

1. Add your AI provider API key as a repository secret

Section titled “1. Add your AI provider API key as a repository secret”

Go to your repository’s Settings > Secrets and variables > Actions and add the API key for your chosen AI provider (e.g. GEMINI_API_KEY for the default Gemini provider). The GitHub Action maps these secret values to the ERODE_-prefixed environment variables that Erode expects.

2. Create the workflow file

Section titled “2. Create the workflow file”

Add .github/workflows/erode.yml to your repository:

name: Architecture Drift Review
on: [pull_request]
jobs:
  erode:
    runs-on: ubuntu-latest
    steps:
      - uses: erode-app/erode@0
        with:
          model-repo: your-org/architecture
          github-token: ${{ secrets.GITHUB_TOKEN }}
          gemini-api-key: ${{ secrets.GEMINI_API_KEY }}

Replace your-org/architecture with the repository that contains your architecture model. The action clones the model repo automatically. No actions/checkout step is needed.

3. Open a code change

Section titled “3. Open a code change”

Erode runs on every code change and posts a comment listing any undeclared dependencies, their severity, and how to fix them. If Erode finds no drift, it confirms the change aligns with the declared architecture.

Try the example project

Section titled “Try the example project”

The playground repository is a ready-made example you can fork and use to try Erode. It contains a multi-service architecture (frontend, API gateway, microservices, database) with pre-configured GitHub Actions workflows for both LikeC4 and Structurizr models.

To try it yourself:

  1. Fork the repository
  2. Add your GEMINI_API_KEY (or another AI provider key) as a repository secret
  3. Open a change that introduces an undeclared dependency

Or browse the existing example PRs to see Erode’s output without any setup:

Undeclared dependency (LikeC4)

Section titled “Undeclared dependency (LikeC4)”

PR #1: feat: add admin users page adds a frontend page that calls user_service directly, bypassing the api_gateway. The architecture model declares that the frontend depends on the gateway, not the service behind it. Erode detects this undeclared dependency and reports the violation on the PR.

Undeclared dependency (Structurizr)

Section titled “Undeclared dependency (Structurizr)”

PR #2: feat: add admin users page introduces the same violation as PR #1, but the analysis runs against a Structurizr workspace instead of a LikeC4 model. The result is the same finding, showing that Erode works across model formats.

New component and model update

Section titled “New component and model update”

PR #3: feat: enrich products with creator info adds a product_service → user_service dependency and introduces a new order_service. Erode detects the undeclared dependency, auto-detects the new component, and after a reviewer replies /erode update-model, creates a model update PR with the proposed changes.