19 lines
1,007 B
Markdown
19 lines
1,007 B
Markdown
# 006 MVP Docker Sandbox Orchestration
|
|
|
|
Context
|
|
- The service needs a first MVP for sandbox orchestration behind `/api/v1/create`.
|
|
- The first version must stay small, avoid auth, and preserve clean architecture boundaries.
|
|
|
|
Decision
|
|
- Use Docker as the outer runtime adapter for sandbox start and stop operations.
|
|
- Keep sandbox entities and errors in `domain/` and orchestration ports in `usecase/`.
|
|
- Use an in-memory session repository for the MVP instead of a central database.
|
|
- Keep one active sandbox per `chat_id` and reuse it until TTL expiry.
|
|
- Set default sandbox TTL to 300 seconds.
|
|
- Mount chat storage as `rw`, dependencies as `ro`, and lambda-tools as `ro`.
|
|
- Run expired sandbox cleanup as an in-process background loop in the HTTP app lifecycle.
|
|
|
|
Consequences
|
|
- Inner layers stay free from Docker and FastAPI details.
|
|
- The MVP is single-instance oriented and not yet suitable for multi-node coordination.
|
|
- Repository and runtime can be replaced later without changing usecase contracts.
|