Genesis-Embodied-AI: Using Genesis with a REST API / Server-side Integration

[Keith-CFC]

Select Topic Area

Question

Body

Hi all,

We’re running Genesis (genesis-world) in a server environment (behind VPN) and are exploring whether anyone has successfully exposed Genesis data or controls via a REST API.

From what I understand, Genesis itself is a Python engine and doesn’t expose a native REST interface, so this would require a custom API layer (e.g. FastAPI/Flask) running alongside the simulation.

Before we go further, I wanted to ask:

• Has anyone here done this in practice?
• Any recommended patterns or pitfalls?
• Is there an established or community-preferred approach for exposing Genesis via HTTP?

I’m not a core Python/backend developer, so real-world examples or guidance would be hugely appreciated.

Thanks in advance,
Keith

[Darksun-Dyuti]

Hi Keith,

Yes—people have exposed Genesis (genesis-world) through a REST-style interface in practice, but you’re correct that Genesis itself does not provide a native HTTP/REST API. The common approach is exactly what you described: a custom API layer that runs alongside (or inside) the simulation process.

While there’s no “official” Genesis REST server, teams commonly:

• Embed Genesis inside a long-running Python service
• Expose selected simulation state and control hooks via FastAPI (most common) or Flask
• Use HTTP for high-level control and data queries, not real-time stepping

This pattern is already familiar to people integrating simulators with:

• Web dashboards
• RL training pipelines
• Remote orchestration systems
• CI / experiment automation

Preferred pattern: single-process, shared state
┌─────────────────────────┐
│ FastAPI (HTTP layer) │
│ │
│ /reset │
│ /step │
│ /state │
│ /metrics │
│ │
│ ┌──────────────────┐ │
│ │ Genesis Engine │ │
│ │ (in-memory) │ │
│ └──────────────────┘ │
└─────────────────────────┘

[saitejabandaru-in]

You’re correct — Genesis (genesis-world) is purely a Python simulation engine and doesn’t provide any built-in REST or network interface, so exposing it over HTTP requires adding your own API layer.

This is actually the pattern most people use in practice:

Genesis process
↓
Python control loop
↓
FastAPI / Flask
↓
REST clients

The usual approach is:
• Run Genesis in a long-lived Python process
• Keep a reference to the simulation world in memory
• Expose endpoints like /step, /reset, /get_state, /set_action via FastAPI or Flask
• Serialize state (positions, sensors, rewards, etc.) to JSON for clients

FastAPI works especially well because it supports async endpoints and WebSockets if you later want streaming updates instead of polling.

The main pitfalls to be aware of:
– Genesis is not thread-safe, so API requests should be serialized (single worker or a request queue)
– Avoid blocking the event loop with long simulation steps (use background tasks or a worker thread)
– Be careful about copying large tensors or images over HTTP; use compression or shared memory if needed

There isn’t a single “official” Genesis REST standard yet, but most community integrations follow this same sidecar-API pattern.

If you’re behind a VPN, this setup works well because the REST layer can be the only exposed surface while Genesis stays fully private.

[github-actions[bot]]

🕒 Discussion Activity Reminder 🕒

This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions:

1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as out of date at the bottom of the page.

2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own.

3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution.

Note: This dormant notification will only apply to Discussions with the Question label. To learn more, see our recent announcement.

Thank you for helping bring this Discussion to a resolution! 💬