WAIT — OpenSSF Scorecard says this is unmaintained

• Last commit 4w ago
• 33+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 55% of recent commits
• ⚠ Scorecard: marked unmaintained (1/10)
• ⚠ Scorecard: dangerous CI workflow (0/10)
• ⚠ Scorecard: default branch unprotected (2/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Sanic is a Python 3.10+ async web framework and ASGI server designed for high-performance web applications using async/await syntax. It provides both HTTP server capabilities and a full web framework with routing, middleware, blueprints, and request/response handling—all built to minimize latency and maximize throughput for fast I/O-bound operations. Monolithic web framework structure: sanic/ contains the core server and routing engine, docs/ holds comprehensive guides and API documentation, tests/ holds the test suite, and examples/ (implied in typical Sanic structure) contain runnable applications. Configuration is centralized with .coveragerc for coverage tracking and pyproject.toml-style packaging.

Python developers building high-performance web APIs and microservices who need async-first request handling without blocking I/O. Contributors are typically backend engineers optimizing web server performance, or framework maintainers extending Sanic's core functionality.

Sanic is production-ready and actively maintained. The codebase shows ~1.9M lines of Python with established CI/CD workflows (.github/workflows/tests.yml, .github/workflows/coverage.yml), comprehensive documentation in docs/, and structured changelog management in changelogs/. The presence of security.md, codeowners, and active GitHub Actions indicate a mature project with professional governance.

Low risk for core stability, but dependency footprint is moderate (sanic-ext, msgspec, libsass, mistune). Breaking changes are tracked in changelogs/ suggesting version management discipline. Main risks: ASGI ecosystem fragmentation (multiple ASGI server options compete), and Python 3.10+ minimum requirement limits legacy compatibility. Monitor the release cadence in .github/workflows/publish-release.yml.

Active development indicated by recent changelogs (1892.removal.rst, 1904.feature.rst, 1970.misc.rst), suggesting feature work and breaking change management. The codebase includes CodeQL security analysis and coverage tracking workflows, showing ongoing security and quality focus.

git clone https://github.com/sanic-org/sanic.git
cd sanic
pip install -e .
pip install -r requirements-dev.txt
make test

Daily commands: After installation, create a minimal app.py:

from sanic import Sanic
from sanic.response import json

app = Sanic("test_app")

@app.route("/")
async def hello(request):
    return json({"hello": "world"})

if __name__ == "__main__":
    app.run(host="127.0.0.1", port=8000)

Then: python app.py (or sanic app.py if CLI is available).

• sanic/app.py — Core Sanic application class that handles routing, middleware, and request/response lifecycle management.
• sanic/router.py — Router implementation responsible for URL pattern matching and route resolution for incoming requests.
• sanic/request.py — Request object abstraction that parses and provides access to HTTP request data, headers, and body.
• sanic/response.py — Response object that constructs and serializes HTTP responses with proper headers and body encoding.
• sanic/blueprints.py — Blueprint module enabling modular application structure by grouping routes and middleware into reusable components.
• sanic/server.py — Server initialization and lifecycle management including worker processes, signal handling, and listener configuration.
• CONTRIBUTING.md — Contribution guidelines and coding standards that all developers must follow when submitting changes.

• Application (Sanic) (Python async/await) — Central coordinator managing routes, middleware, and request/response lifecycle
  • Failure mode: Crashes entire application; restart required
• Router (Trie-based matching) — Matches incoming URL patterns to registered handlers using trie data structure
  • Failure mode: No matching route returns 404; unmatched requests discarded
• Request Parser (msgspec, asyncio streams) — Extracts and decodes HTTP headers, query parameters, body content from raw HTTP
  • Failure mode: Malformed requests return 400 Bad Request
• Response Builder (msgspec, content encoding) — Constructs HTTP response with status code, headers, body serialization
  • Failure mode: Serialization errors return 500 Internal Server Error
• Middleware Stack (Python async context managers) — Executes request/response interceptors in order for cross-cutting concerns
  • Failure mode: Unhandled exception in middleware returns 500 or propagates to error handler
• Server/Worker Manager (multiprocessing, signal handlers) — Spawns and manages multiple worker processes, handles signals, lifecycle events
  • Failure mode: Worker crash terminates that process; supervisor must restart

• HTTP Client → Sanic Server — Raw HTTP request bytes received on configured port/socket
• Sanic Server → Request Parser — Raw HTTP stream parsed into headers, method, path, query params, body
• Request Parser → Router — Parsed request metadata (method, path) matched against registered routes
• Router → Route Handler — Matched handler function called with Request object and path parameters
• Route Handler → Response Builder — Handler returns Response object or data structure to be serialized
• Response Builder → HTTP Client — Serialized HTTP response with status, headers, encoded body sent back to client

Add a New HTTP Route

1. Use the @app.route() decorator to register a new HTTP endpoint with method and path (sanic/app.py)
2. Define async handler function accepting request parameter and returning Response object (sanic/response.py)
3. Access request data via request object properties (args, json, headers, etc.) (sanic/request.py)

Create a Modular Blueprint

1. Create Blueprint instance with name and url_prefix to group related routes (sanic/blueprints.py)
2. Register routes and middleware using @blueprint.route() and @blueprint.middleware() (sanic/blueprints.py)
3. Register blueprint with app using app.blueprint() in main application file (sanic/app.py)

Add Request/Response Middleware

1. Define async middleware function with request parameter and optional response (sanic/app.py)
2. Register middleware using @app.middleware('request') or @app.middleware('response') (sanic/app.py)
3. Middleware executes before/after route handlers to intercept and modify requests or responses (sanic/app.py)

Handle Static Files

1. Use app.static() to register static file directories or individual files (sanic/app.py)
2. Specify URI path and file system path for static asset serving (examples/static_assets.py)

• AsyncIO (Python async/await) — Enables non-blocking concurrent request handling with minimal overhead for I/O-bound web operations
• uvloop (optional drop-in replacement) — Provides faster event loop implementation than standard asyncio for improved throughput
• msgspec — High-performance serialization for JSON encoding/decoding in request/response bodies
• Trie-based routing — O(1) route matching performance with support for path parameters and wildcards

• Async-only framework (no synchronous handler support)

  • Why: Forces consistency and prevents blocking operations from starving other requests
  • Consequence: Developers must use async libraries and cannot reuse blocking third-party code without adapters

• Single-process with multiprocessing workers instead of threading

  • Why: Avoids Python GIL contention and provides true parallelism across CPU cores
  • Consequence: Shared state requires IPC mechanisms; more memory overhead per worker

• No built-in ORM or database layer

  • Why: Maintains framework flexibility and avoids tight coupling to specific database solutions
  • Consequence: Developers must integrate third-party database libraries independently

• Does not provide built-in authentication or authorization mechanisms
• Does not include an ORM or database abstraction layer
• Does not handle synchronous blocking operations (all handlers must be async)
• Does not provide template rendering (separate templating libraries required)
• Does not include session management (use external session stores)

• Avg cyclomatic complexity: ~6 — Sanic core modules have moderate complexity due to async/await patterns, middleware chains, and request parsing logic; router complexity is hidden in C extensions or optimized Python structures
• Largest file: sanic/app.py (2,500 lines)
• Estimated quality issues: ~4 — Modern codebase with type hints and structured design; minor issues in error handling consistency and global state management across workers

• Blocking operations in handlers (High) — sanic/request.py, sanic/response.py: Using synchronous/blocking calls in async handlers blocks entire event loop and degrades concurrency
• Global mutable state without synchronization (High) — sanic/app.py: Shared application state accessed from multiple worker processes without proper locking causes race conditions
• Catching overly broad exceptions (Medium) — sanic/app.py: Catching Exception or bare except clauses masks programming errors and makes debugging difficult

• sanic/router.py (Algorithmic complexity) — Route matching with deeply nested trie structures or many wildcard routes can slow request dispatch
• sanic/request.py (I/O bound) — Parsing large request bodies or headers requires reading from socket stream which may block on I/O
• sanic/response.py (CPU bound) — Serialization of large JSON responses using msgspec is CPU-bound before transmission
• sanic/server.py (Process management) — Worker process spawning and IPC overhead increases latency during startup with many workers

1. ASGI compliance is strict: responses must be fully async-compatible; blocking I/O in handlers will stall the entire event loop. 2. Minimum Python 3.10: older projects cannot use this—check .python-version or CI constraints in .github/workflows/tests.yml. 3. Configuration via app.config: global settings must be set before app.run() or registered in startup listeners, or they won't take effect. 4. Middleware registration order matters: middleware added via @app.middleware('request') runs in registration order; reverse order for 'response'. 5. Blueprint naming: blueprint routes inherit the blueprint name as a prefix unless explicitly configured; name collisions cause silent overwrites.

• ASGI (Asynchronous Server Gateway Interface) — Sanic is ASGI-compliant, meaning it implements a standard async interface allowing deployment on any ASGI server (Uvicorn, Hypercorn); understanding ASGI scope/receive/send is essential for middleware and server lifecycle hooks
• async/await and asyncio event loop — All Sanic handlers and middleware are async functions running on a single event loop; non-blocking I/O is fundamental—blocking calls will stall the entire application
• Middleware pipeline and request/response lifecycle — Sanic routes requests through ordered middleware (via @app.middleware decorators) before hitting handlers and responses; understanding this pipeline is critical for adding cross-cutting concerns like auth or logging
• Blueprint modular routing — Blueprints group related routes and middleware into reusable modules (imported and registered on the app)—essential pattern for scaling Sanic apps beyond monolithic files
• Streaming responses and chunked HTTP — Sanic supports streaming large responses without buffering in memory via file_body or stream_body—critical for file downloads and real-time data feeds in high-performance scenarios
• HTTP/1.1 Keep-Alive and connection pooling — Sanic reuses TCP connections across multiple requests; understanding how persistent connections work is important for performance tuning and debugging slow clients
• Signal/event system (Sanic listeners and signals) — Sanic fires signals at app startup, shutdown, and request lifecycle stages (@app.before_server_start, @app.on_request_middleware, etc.); hooks here replace traditional Flask signal patterns for async apps

• pallets/flask — Synchronous predecessor to Sanic—Flask is the reference WSGI framework Sanic improves upon by adding async/await support and ASGI
• encode/starlette — Direct alternative ASGI framework emphasizing simplicity; both target async Python developers but Sanic adds full framework features where Starlette stays lightweight
• tiangolo/fastapi — Built on Starlette but adds Pydantic validation and OpenAPI docs; competes with Sanic for high-performance API development with type hints
• sanic-org/sanic-ext — Official extension library for Sanic providing OpenAPI/Swagger, validation, CORS—referenced in dependencies and docs as the standard plugin ecosystem
• aio-libs/aiohttp — Lower-level async HTTP client/server library; Sanic sits at a higher abstraction layer for request routing, while aiohttp offers more control

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive security testing workflow for known vulnerabilities

The repo has bandit.baseline and SECURITY.md but no dedicated GitHub Actions workflow for security scanning. Given Sanic's focus on performance and being a web framework (security-critical), adding a workflow that runs bandit, safety checks, and trivy vulnerability scanning on each PR would help catch security regressions early. This is especially important since the dependencies include msgspec and libsass which are native extensions.

• [ ] Create .github/workflows/security-scan.yml that runs bandit against the sanic package with the baseline
• [ ] Add safety check step to scan Python dependencies for known CVEs
• [ ] Add trivy container image scanning step for the docker/ images (Dockerfile and Dockerfile-base)
• [ ] Configure the workflow to run on all PRs and pushes to main branches
• [ ] Reference and update SECURITY.md with instructions on reporting security issues found by the workflow

Create missing changelog entries for unreleased changes in changelogs/ directory

The changelogs directory exists with entries like 1892.removal.rst, 1904.feature.rst, 1970.misc.rst but there's a .gitignore file there, suggesting the structure is in place. However, there's no documented workflow or template for contributors to follow when adding changelog entries. Creating a changelogs/README.md and a sample template will reduce friction for new contributors and ensure consistent formatting across changelog fragments.

• [ ] Create changelogs/README.md explaining the towncrier-style changelog format (type.number.rst)
• [ ] Create changelogs/.template.rst as an example template showing feature, bugfix, removal, and misc entry formats
• [ ] Update CONTRIBUTING.md with a 'Changelog Entries' section referencing the changelogs/README.md
• [ ] Add a GitHub Actions check to validate that PRs touching core files include appropriate changelog entries

Expand test coverage for example scripts with integration tests

The examples/ directory contains many example files (add_task_sanic.py, amending_request_object.py, authorized_sanic.py, blueprint_middlware_execution_order.py, etc.) but there's no apparent test coverage for these examples. These examples serve as documentation and should be verified to work correctly. Adding integration tests that run each example and verify expected behavior would prevent documentation rot and catch breaking changes.

• [ ] Create tests/integration/test_examples.py to import and verify each example file in examples/ runs without errors
• [ ] For key examples like authorized_sanic.py and blueprint_middlware_execution_order.py, add assertions that verify expected app structure and route registrations
• [ ] Add a GitHub Actions workflow step in .github/workflows/tests.yml to run example tests as part of the test suite
• [ ] Create a examples/README.md documenting what each example demonstrates and any prerequisites needed to run them

• Add comprehensive docstring coverage to sanic/router.py's route matching logic—currently underdocumented for new contributors trying to understand parameter extraction patterns.
• Write integration tests in tests/ for error handling across different response types (JSON, streaming, file) to verify consistent exception serialization across content types.
• Expand docs/sanic/guide/ with a 'Testing Sanic Applications' section showing how to use async test fixtures with pytest-asyncio, since the docs/ structure suggests guide content is incomplete.

The Sanic framework codebase demonstrates a reasonable security posture with CodeQL analysis and a documented security policy. However, several areas require attention: (1) Dependency version constraints lack upper bounds, creating reproducibility and security risks; (2) Markdown processing libraries could introduce XSS vulnerabilities without proper sanitization; (3) Docker files lack explicit vulnerability scanning in the CI/CD pipeline; (4) Bandit security scanning exists but integration into the automated workflow is not evident. The presence of SECURITY.md and documented policies is positive, but enforcement through automated tooling should be strengthened. No hardcoded secrets or obvious SQL injection patterns were detected in the visible file structure.

• Medium · Dependency Version Pinning Not Specified — Dependencies/Package file (sanic>=23.12, sanic-ext>=23.12, etc.). The dependencies in the package file use loose version constraints (e.g., 'sanic>=23.12' without upper bounds). This allows installation of newer versions that may contain security vulnerabilities or breaking changes. Without pinned versions, reproducible builds and security patches cannot be guaranteed across environments. Fix: Implement strict version pinning or specify version ranges with upper bounds (e.g., 'sanic>=23.12,<24.0'). Use a lock file (requirements.lock or poetry.lock) to ensure reproducible builds. Regularly audit and update dependencies.
• Low · Markdown Library (mistune) Version Not Constrained — Dependencies/Package file (mistune). The 'mistune' dependency for markdown parsing lacks version constraints. Markdown parsing libraries can have XSS vulnerabilities if not properly configured. Without version constraints, vulnerable versions could be installed. Fix: Pin mistune to a specific secure version (e.g., 'mistune>=2.0.0,<3.0'). Ensure HTML sanitization is enabled when rendering markdown. Review mistune security advisories and update regularly.
• Low · Potential XSS Risk in Documentation/Template Processing — docs/_templates, docs/conf.py, and markdown processing pipeline. The codebase includes 'python-frontmatter' and 'mistune' for markdown processing with template support (indicated by '_templates' directory and Sphinx documentation). If user-controlled content is processed without proper sanitization, this could lead to XSS vulnerabilities. Fix: Implement content security policy (CSP) headers. Sanitize all user-controlled input before rendering. Use a HTML sanitization library like 'bleach' for any dynamic content. Validate and escape template variables.
• Low · Docker Files Present Without Security Scanning — docker/Dockerfile, docker/Dockerfile-base, examples/Dockerfile, .github/workflows. Docker files are present (docker/Dockerfile, docker/Dockerfile-base, examples/Dockerfile) but the codebase structure does not show explicit security scanning or base image vulnerability checks in the CI/CD configuration. Fix: Implement Docker image scanning in CI/CD pipelines using tools like Trivy or Snyk. Use minimal base images (alpine). Scan for vulnerabilities before publishing. Implement SBOM (Software Bill of Materials) generation.
• Low · No Evidence of Security Scanning in CI/CD — .github/workflows/, bandit.baseline. While CodeQL analysis workflow is present (.github/workflows/codeql-analysis.yml), there is no visible evidence of SAST (Static Application Security Testing) tools like Bandit being integrated into the CI/CD pipeline. A 'bandit.baseline' file exists but integration is unclear. Fix: Integrate Bandit security scanning into the CI/CD pipeline to catch Python security issues. Enforce passing security checks before merging. Include dependency vulnerability scanning (e.g., Safety, Snyk). Document security requirements in CONTRIBUTING.md.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/sanic-org/sanic shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live sanic-org/sanic repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/sanic-org/sanic.

What it runs against: a local clone of sanic-org/sanic — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in sanic-org/sanic | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 57 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of sanic-org/sanic. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/sanic-org/sanic.git
#   cd sanic
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of sanic-org/sanic and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "sanic-org/sanic(\\.git)?\\b" \\
  && ok "origin remote is sanic-org/sanic" \\
  || miss "origin remote is not sanic-org/sanic (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "sanic/app.py" \\
  && ok "sanic/app.py" \\
  || miss "missing critical file: sanic/app.py"
test -f "sanic/router.py" \\
  && ok "sanic/router.py" \\
  || miss "missing critical file: sanic/router.py"
test -f "sanic/request.py" \\
  && ok "sanic/request.py" \\
  || miss "missing critical file: sanic/request.py"
test -f "sanic/response.py" \\
  && ok "sanic/response.py" \\
  || miss "missing critical file: sanic/response.py"
test -f "sanic/blueprints.py" \\
  && ok "sanic/blueprints.py" \\
  || miss "missing critical file: sanic/blueprints.py"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 57 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~27d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/sanic-org/sanic"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.