Savine Documentation

From Prototype to Production ​

Moving an agent from a local test run to a production environment requires tightening security, managing costs, and configuring observability pipelines. Do not merge a system.json to main without completing this checklist.

The Pre-Production Checklist ​

  • [ ] 1. Security Level Review: Ensure the agent's security_level in config is set to high or critical if it has no outbound HTTP requirements. Decrease it from low immediately if left from local testing.
  • [ ] 2. Domain Allowlist: If using the http_request tool, specify the exact array of allowed_domains in your agent.json.
  • [ ] 3. Timeout Limits: Adjust timeout_seconds down to the smallest possible window. Do not leave the 1-hour default running.
  • [ ] 4. Error Boundaries: Set your retry_limit sensibly (usually 3).
  • [ ] 5. Alerting Setup: In the Savine Dashboard, go to Settings > Alerting and configure Webhook or Slack alerts for LoopDetection, TaskFailed, and DailyBudgetHit events.
  • [ ] 6. CI/CD Integration: Check that the GitHub app is installed on your production repository to enable automatic schema validation on Pull Requests.
  • [ ] 7. API Key Rotation: If your prototype used personal API keys (e.g. your OpenAI account), generate service-account API keys, and update them securely using savine config set.
  • [ ] 8. System Architecture Validated: Before going live, run savine systems validate system.json on your exact deployed infrastructure files.

Load Testing ​

Savine automatically scales sandboxes horizontally. However, your BYOK LLM Provider (OpenAI, Anthropic) enforces steep "Tokens per Minute" rate limits.

If you hammer Savine with 1,000 tasks concurrently, the sandboxes will spin up instantly, but OpenAI will likely return HTTP 429 Too Many Requests.

The Solution: Set the max_concurrency setting in the system.json config. Savine will hold excess tasks in the QUEUED state until your LLM provider's rate limits lift.

Auto-Deploy Configuration ​

  1. Connect GitHub in the Savine Dashboard.
  2. Select your production repository.
  3. Every commit pushed to main instantly triggers a redeploy if the configuration hashes have changed.
  4. Old versions are kept historically. You can unarchive a bad automated deployment by clicking Rollback in the UI.