Comparing Hosted Agents and Self-Hosted Tools for Your MVP Runtime
Choose hosted execution when its documented environment meets your workload and your team prefers managed compute. Choose self-hosted execution when a verified requirement needs your own image, compute or private-network access. In either case, test recovery, output preservation and data flows; neither option automatically establishes better privacy or reliability.
The Agents API overview distinguishes the OpenAI-managed harness and durable session from the optional execution environment. Self-hosting tools does not mean hosting the model or harness yourself.
1. Environment Control
OpenAI-hosted sandboxes provide a Linux workspace. You can configure Python, system and global npm packages, setup commands and input files. Each session has a separate workspace. Network access can be enabled, disabled or restricted to listed hosts. These are real configuration options; do not describe hosted environments as incapable of installing software. See hosted sandbox configuration.
A self-hosted executor lets your team choose the image, compute and network configuration, subject to your infrastructure and permission policies. Use it when the workload needs your own private-network path or image. Your team also operates that environment.
2. Task Recovery and Session Durability
A hosted sandbox may be deleted after activity and keep-alives stop for an hour. Connected environments receive keep-alives between turns; closing an event stream does not cancel the task. Files under /workspace/outputs become immutable artifacts when a turn completes and remain downloadable after sandbox expiry. Unfinished local work needs its own recovery design. See hosted files and lifetime.
With self-hosted execution, your team can implement persistent storage and checkpoints. That is an opportunity to design recovery, not proof that tasks automatically resume or lose less data. Test an interrupted representative workflow under either arrangement.
3. Integration Ownership
Hosted setup supports packages, skills, plugins and MCP connections within the documented policies. Verify the required dependency and authorised network path against the real workload.
With self-hosted execution, your team configures the internal integration path. The self-hosted environment guide explains that OpenAI runs the harness while the executor receives commands and returns results over outbound connections. Do not describe these integrations as unrestricted; apply explicit permissions and egress controls.
4. Operational Complexity and Cost
Hosted execution reduces your responsibility for provisioning its compute. Model and tool usage remain separate cost drivers. Self-hosting adds your chosen infrastructure, monitoring, patching and recovery responsibilities. Estimate both using the same representative task and operating assumptions rather than assigning an untested cost advantage.
5. Data Privacy and Compliance
Map content sent to the model, executor and connected services. Local execution does not establish that all data stays in your infrastructure: tool results can reach the OpenAI-managed harness. Review the official OpenAI data controls, relevant endpoint retention and account eligibility. Ask the accountable owner to review applicable privacy obligations; runtime selection alone is not compliance evidence.
6. Development Velocity
Compare the time to a verified user outcome. Hosted execution may reduce environment setup work when the supported configuration fits. Self-hosting may be necessary for a required image or internal network. Neither label guarantees faster delivery or production readiness.
7. Supported Features and Limitations
Record each required package, external service and output format. Test setup success, the permitted connection and the artifact download. Choose self-hosting when a verified environment requirement warrants it, rather than assuming every custom dependency is prohibited in hosted execution.
8. Security Considerations
Hosted configuration permits ordinary environment variables, which agent-generated code can read. The hosted environment documentation directs developers to vault credentials for secrets so real values remain outside the sandbox. Follow and test the relevant vault integration.
For self-hosting, your team owns local isolation, network controls and secret handling. More control does not itself make the workload safer. Test denied operations, credential exposure in logs and the exact data sent to connected services.
Practical Runtime Decision Worksheet for AI MVP
| Criterion | Hosted Agent (OpenAI) | Self-Hosted Environment | Decision (✓) |
|---|---|---|---|
| Environment control | Limited to sandbox config | Full OS and network control | |
| Task recovery | Durable session; plan workspace and artifact lifetime | Implement and test local recovery | |
| Integration ownership | Limited external/private API access | Full integration with internal tools | |
| Operational overhead | Low, managed by OpenAI | High, requires DevOps | |
| Data privacy/compliance | Review provider data flows and controls | Review local and OpenAI harness data flows | |
| Development speed | Fast prototyping | Longer setup | |
| Supported features | Python, Node.js, shell, built-in tools | Any software/tools | |
| Security management | OpenAI managed sandbox, vault for secrets | Your own security policies |
How to use: Identify mandatory requirements first. Reject an option only when verified evidence shows it cannot meet one. Compare operating effort and cost among the options that pass. Record evidence beside each tick; a majority of ticks cannot override a failed requirement.
Worked Example: Research Feature MVP
In this hypothetical example, a South African SaaS startup wants to build an MVP for a user-facing research assistant that queries internal databases, processes data, and generates reports.
- Environment control: Needs access to internal APIs and databases.
- Task recovery: Must resume long-running queries if interrupted.
- Integration ownership: Requires custom API tokens and private network access.
- Operational overhead: Has a small DevOps team.
- Data privacy: Must comply with South African data laws.
- Development speed: MVP launch in 3 months.
Worksheet application:
| Criterion | Hosted Agent | Self-Hosted | Decision |
|---|---|---|---|
| Environment control | ✓ | ✓ | |
| Task recovery | ✓ | ✓ | |
| Integration ownership | ✓ | ✓ | |
| Operational overhead | ✓ | ||
| Data privacy/compliance | ✓ | ✓ | |
| Development speed | ✓ | ||
| Supported features | ✓ | ✓ | |
| Security management | ✓ | ✓ |
Result: Self-hosted environment is recommended despite higher operational overhead due to critical integration and compliance needs.
Detailed Task Recovery Strategies for MVP Runtime
Separate three things: the durable agent session, the executor's unfinished local work and completed downloadable artifacts. A dropped stream is not the same event as deletion of an execution environment. A long task is not automatically disqualified by the hosted inactivity rule because activity and keep-alives matter.
Proposed Recovery Workflow Example
- Store the API session identifier with your application's conversation record.
- Record the running task and last verified checkpoint.
- Save completed deliverables through the documented artifact path or your authorised application storage.
- Interrupt the stream, executor connection and process separately in controlled tests.
- Inspect saved session state, local files and artifacts before deciding whether to resume or rerun.
- Prevent a resumed task from repeating an external side effect already completed.
For self-hosted execution, persistent volumes and process monitoring are choices your team must implement. The official self-hosted guide documents executor reconnection, but that does not guarantee application-level recovery of every task. For hosted execution, verify the completed output remains downloadable after workspace expiry. Record what happens to unfinished work without claiming it is guaranteed to survive.
Choose a runtime from this evidence. Task duration alone and an untested statement about smoother recovery are insufficient grounds for recommending one option.
Integration Ownership and Security: Practical Implications for MVPs
List the minimum service connections and permissions needed for the research feature. For each, record the destination, authorised data, credential owner and failure behaviour. Hosted outbound networking is configurable; self-hosting is appropriate when your own private-network route or compute environment is required.
Do not place a production API key in a readable file simply to make a demonstration work. Use the documented credential mechanism, then verify that unauthorised destinations and operations are denied. Test the actual required dependency instead of stating that hosted execution prohibits custom packages.
Self-hosting keeps the executor under your operating control, while OpenAI still runs the harness. Inspect the results sent back to that harness and any third-party tool. Have the accountable owner review data-processing requirements and provider controls. Encryption is one control, not proof of compliance with South African privacy obligations.
Worked Hypothetical Case: MVP Runtime Decision for a South African Research SaaS Startup
Scenario:
A Cape Town-based startup is building an AI-powered research assistant MVP for legal professionals. The feature queries internal legal databases, processes case documents, and generates summaries.
Key MVP requirements:
- Access internal PostgreSQL and document storage APIs behind a VPN.
- Support task resumption for queries that may take up to 2 hours.
- Ensure compliance with POPIA for data privacy.
- Deliver MVP within 3 months with a small DevOps team.
Step 1: Evaluate Environment Control
- Hosted agent: Cannot access internal VPN or private APIs.
- Self-hosted: Team can configure and test an authorised VPN path.
Decision: ✓ Self-hosted
Step 2: Task Recovery
- Hosted agent: Durable session and managed workspace; verify interruption behaviour and preservation of completed artifacts.
- Self-hosted: Can implement persistent storage and process monitoring.
Decision: ✓ Self-hosted
Step 3: Integration Ownership
- Hosted agent: Configurable outbound access and supported dependency setup; check the required private-network path.
- Self-hosted: Team can configure and test the required internal integrations.
Decision: ✓ Self-hosted
Step 4: Operational Overhead
- Hosted agent: Minimal overhead.
- Self-hosted: Requires DevOps effort.
Decision: ✓ Hosted agent (but balanced by other needs)
Step 5: Data Privacy and Compliance
- Hosted agent: Data processed on OpenAI infrastructure; review compliance.
- Self-hosted: Execution is local, but command results can reach the OpenAI harness; assess those flows explicitly.
Decision: ✓ Self-hosted
Step 6: Development Speed
- Hosted agent: Faster prototyping.
- Self-hosted: Longer setup.
Decision: ✓ Hosted agent (but offset by critical needs)
Final Decision: Self-hosted environment is chosen due to critical integration, recovery, and compliance requirements despite higher operational overhead and setup time.
Acceptance Tests for the Chosen Runtime
| Test Case | Expected Result | Failure Recovery Step |
|---|---|---|
| Agent connects to internal APIs | Agent successfully queries internal databases via VPN | Check VPN connectivity; restart executor; verify credentials |
| Task interruption and resume | Agent resumes query from last checkpoint after restart | Review checkpoint logs; implement retry logic |
| Secret injection | API keys loaded securely without exposure in logs or code | Rotate secrets; audit vault access |
| Data-flow review | Record content sent to OpenAI and other services; verify configured controls | Reduce exposed data or revise the design where requirements cannot be met |
Practical Worksheet Fields to Record
- Environment type: Self-hosted
- Workspace directory:
/workspace - Executor version: Record the actual installed version after verification.
- VPN endpoint:
vpn.company.local - Persistent storage path:
/workspace/outputs - Secret management system: HashiCorp Vault
- Lifetime policy: Record provider behaviour, application cleanup and tested reconnection limits.
- Recovery checkpoint interval: Every 5 minutes
- Operations contact: Record the named, authorised support owner.
This practical approach helps founders and product owners in South Africa make an informed, evidence-based decision on the runtime environment for their AI MVP research features using the OpenAI Agents API beta.
Frequently Asked Questions
What is the Agents API and how does it relate to hosted vs self-hosted?
The API manages the harness and sessions while your application chooses where tools run. A self-hosted executor remains connected to that OpenAI-managed harness; it is not a locally hosted model.
Can I switch from hosted to self-hosted later?
Yes, the API supports both. You can prototype with hosted agents then migrate to self-hosted for production as your needs evolve.
How do I manage secrets securely in hosted agents?
Use OpenAI’s vault credentials feature to inject secrets at runtime without exposing them in the sandbox environment variables or files.
Are there cost differences?
Hosted agents incur container usage and API call costs managed by OpenAI. Self-hosted costs depend on your infrastructure and maintenance.
If your business needs help deciding or implementing the right runtime for your MVP, consider our expert SaaS MVP development services at MVP Development. For broader SaaS strategy and product planning, visit our SaaS Development page.
For more on integrating AI features and managing user experience, review our Discovery Phase Checklist and understand the User Journey to align your product roadmap.
If you need help balancing rapid MVP delivery with environment control, get in touch through our MVP Development service route.