diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
new file mode 100644
index 0000000..d428147
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,14 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: "[BUG]"
+labels: bug, pending-review
+assignees: ''
+
+---
+
+**Worker compose with built-in 1..5 scale presets:** Root `**docker-compose.worker.yml**` defines `**backend-worker-1..5**` with profile gates so scaling is a single env var: default = 1 worker, `**COMPOSE_PROFILES=w3**` = 3 workers, `**COMPOSE_PROFILES=w5**` = 5 workers. Example: `**COMPOSE_PROFILES=w3 docker compose -f docker-compose.worker.yml up -d --build**` with `**DATABASE_*`**, `**REDIS_*`**, and `**STRIPE_SECRET_KEY**` set (see file header).
+
+To run several workers on one host, duplicate the service with different `**WORKER_ID**` / `**RIVER_WORKER_METRICS_PORT**` (and optional `**ports:**` mappings for host access to metrics) or use `**docker compose up --scale**` without host port bindings.
+
+Deploy workers on `**PROJECT_DOCKER_NETWORK` only** — same mesh as Postgres and Redis — with **no** public domains unless you intentionally expose metrics behind auth.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
new file mode 100644
index 0000000..7ab79ff
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -0,0 +1,41 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: "[FR]"
+labels: enhancement, pending-review
+assignees: ''
+
+---
+
+## Feature request — InboundParse
+
+### Summary
+One sentence: what you want and why it matters.
+
+### Problem / motivation
+What workflow or limitation exists today? Who benefits (operators, integrators, end users)?
+
+### Proposed solution
+Describe the behavior or API you want. Be specific where it helps (config keys, flags, HTTP/SMTP semantics).
+
+### Alternatives considered
+Other ways you thought of solving this, and why this approach is preferred (or acceptable tradeoffs).
+
+### Scope & constraints
+- **In scope:** …
+- **Out of scope / non-goals:** …
+- **Backward compatibility:** Must existing configs keep working? Migration acceptable?
+
+### Acceptance criteria
+Checklist of what “done” looks like (testable bullets).
+
+### Documentation & observability
+- Docs or examples that should change.
+- Metrics, logs, or health checks that should reflect the new behavior (if any).
+
+### Environment / version (if relevant)
+InboundParse version or commit you’re targeting; how you deploy (optional).
+
+### Checklist
+- [ ] I searched existing issues / discussions for duplicates.
+- [ ] This request is focused on one coherent feature (not a bundle of unrelated asks).