Skip to main content

Live Apps

Live Apps are robust, long-lived services designed to host and deploy web applications on the MINEO platform. They cater to various frameworks such as Streamlit, Gradio, FastAPI, or any custom entrypoint you wish to implement.

In contrast to ephemeral notebook workers, Live Apps offer a persistent environment and are available to all users until a manual stop is initiated. This makes them ideal for applications that require a stable and consistent runtime.

Features​

FeatureDescription
Seamless DeploymentDeploy any web framework that listens on port 8000, ensuring broad compatibility and hassle-free integration with the platform's infrastructure
Persistent ServicesYour app remains active and accessible across multiple sessions and users, unless stopped manually
Dedicated ResourcesEach app benefits from allocated resources, guaranteeing consistent and optimal performance without interference from other processes
Docker-based EnvironmentRecreate and manage your app's environment effortlessly with Docker, ensuring reproducibility and minimizing configuration issues
Example

To deploy a Streamlit app, place a functional app.py in your working directory and use the following entrypoint:

pip install --no-cache-dir streamlit && streamlit run app.py --server.port 8000

Configuration options:​

The Live App configuration form is organized into four logical sections for better usability:

📋 Basic information​

Configure your app's identity and access settings:

FieldDescription
NameRequired identifier for your app, unique within the project
Working directoryFolder that holds your app's code; the entrypoint runs from here
DescriptionOptional description for your app to help users understand its purpose
SlugCustom URL slug for the app (e.g., my-app). If not set, a UUID will be used. This creates your app's unique identifier
URLA unique URL is automatically generated based on your slug or domain. This is where users will access your app. More information in the Organization's slug or domain
Login requiredIf checked, users must be logged in and have viewing permission to access the app. Enable this for private or sensitive applications

💻 Execution configuration​

Set up how your app runs:

FieldDescription
EntrypointShell command used to start your app. Ensure it listens on port 8000 for proper functionality

🔗 Connection​

Configure how the app is used and how the platform checks that it is ready after wake-up:

FieldDescription
App typeWeb apps are opened by people in the browser, with optional MINEO login. MCP apps are used by Assistants as MCP servers: MINEO login is disabled and clients authenticate with tokens
App main pathPath probed on the worker to check readiness after wake-up (e.g. /health or /). Defaults to /

Apps created from the FastMCP preset or the MCP Template are configured automatically: MCP type, login disabled, and On-demand availability, so Assistants can wake them whenever they need them.

Readiness check

After wake-up, MINEO sends an HTTP GET to App main path and accepts any response below 500 — redirects, app-level login walls, 404s and MCP servers rejecting a plain GET all prove the app is up. 5xx responses and connection failures keep the request waiting. Point App main path to a route that does not fail with a server error, such as / or /health.

🔌 Availability​

Choose how your app's running lifecycle is managed with the Availability selector. The four modes are mutually exclusive:

ModeBehavior
On-demandThe app hibernates after the Inactivity timeout and wakes up automatically when someone opens it. The first request may take longer while the application starts
Wake using buttonThe app hibernates after the Inactivity timeout. Shows a wake-up page with a button; clicking it starts the application
ScheduledThe app stays powered on during a recurring weekly window; outside it, wakes up automatically on request. Premium feature that requires an appropriate pricing plan
Always onThe app runs continuously and is never hibernated. Premium feature that requires an appropriate pricing plan
info

Each request waits independently for up to 200 seconds. If the app does not become ready in time, a 504 Gateway Timeout is returned. Waiting does not block other users' requests.

When the app cannot be served, the URL answers with an explanatory page and a meaningful status code, so monitors and API clients can tell the cases apart: 404 when the app does not exist, 503 when it exists but is stopped, and 503 when it is hibernated without automatic wake-up.

Manual hibernation and wake-up​

While an app is running, open the dropdown on the Stop button in the detail view and select Hibernate. Hibernating frees the worker immediately but, unlike stopping, keeps the app eligible for automatic wake-up (on demand, with the wake-up button, or by schedule). Use it to release resources without taking the app offline.

While an app is hibernated, the same dropdown offers Wake up, which starts it again without waiting for an incoming request.

⏰ Scheduled mode​

Define a recurring window during which the app stays available, without keeping it running 24/7:

  • Pick the Power-on days (one or more days of the week) and the Power-on hours (a start–end time range, which may cross midnight).
  • Set the Off-window inactivity timeout that applies outside the window.
  • Inside the window: the app is powered on automatically at the start time and is never hibernated by inactivity.
  • Outside the window: the normal inactivity rules apply — the app hibernates when idle, and any incoming request wakes it up automatically.
info

Times are evaluated in the server timezone. The form shows that timezone and the current server time below the Power-on hours field so you can set the window accordingly.

⚙️ Resource settings​

Control resource management and lifecycle:

FieldDescription
Worker ImageThe container image used to run your app, either the default project image or a custom one tailored to your app's specific dependencies. Learn more about Worker Images
Worker environmentThe machine resources (RAM, CPU, GPU) allocated to run your app. Choose based on your app's computational requirements

With these options, Live Apps provide a powerful and flexible environment for deploying applications, encouraging collaboration and innovation within the MINEO ecosystem. Workers which are ephemeral and user-specific, Live Apps are shared persistent services that remain available until explicitly stopped.

Your current plan’s maximum number of Live Apps is shown in the action bar, to the left of the Run button. This quota counts Active apps, which means both Hibernated and Running states consume a slot. To free a slot, fully stop an app; hibernating it does not reduce the count.

Public API​

The API lets an external system control a Live App programmatically — power it on, power it off, hibernate it, or read its current state — without a user session.

All endpoints require a valid project token. Add it to the Authorization header:

Authorization: Token YOUR_ACCESS_TOKEN

Tokens are created per project from Project Settings / API (see Projects). A token only authorizes Live Apps that belong to its own project, and it can be revoked at any time.

Open the Live App's API tab to get ready-to-run curl and Python examples for that app; paste a token to fill them in.

Power on​

POST /api/project/{project_uuid}/live-apps/{live_app_uuid}/run/

Starts the app, whether it was stopped or hibernated. Returns the app with its new state.

{
    "uuid": "b7f1c0de-1234-4a5b-9c8d-0e1f2a3b4c5d",
    "name": "my-app",
    "slug": "my-app",
    "status": "starting",
    "url": "https://acme.mineo.app/my-app"
}

Power off​

POST /api/project/{project_uuid}/live-apps/{live_app_uuid}/stop/

Stops the app and leaves it disabled: incoming traffic does not restart it, so the app only runs again after an explicit power-on. Frees the Live App quota slot. Returns the same payload as Power on.

Scheduled apps restart on their own

Powering off is not permanent for an app in Scheduled availability mode: its activation window powers it on again at the next start time. Turn off the schedule if you need the app to stay down.

Hibernate​

POST /api/project/{project_uuid}/live-apps/{live_app_uuid}/hibernate/

Stops the app but keeps it eligible for automatic wake-up, so incoming traffic starts it again, following the Availability mode configured for the app. The app must be running. Hibernated apps keep consuming a quota slot. Returns the same payload as Power on.

Get state​

GET /api/project/{project_uuid}/live-apps/{live_app_uuid}/status/

{
    "status": "running"
}

State values​

ValueMeaning
runningA worker is assigned and reachable. Right after a power-on the worker may still be booting, so the first request can wait for the app to become ready
startingA worker is being provisioned and has no address yet
hibernatedStopped, and incoming traffic wakes it up automatically
stoppedStopped and disabled; only an explicit power-on starts it
unavailableMarked as running but has no live worker; power it on again

Error responses​

StatusWhen
403Missing, malformed, expired, or wrong-project token; or Live Apps are not enabled for the project or its pricing plan
404The Live App does not exist in this project
400The action does not apply to the current state — hibernating an app that is not running returns LIVEAPP_NOT_RUNNING
406No worker capacity, no worker plan configured, or the cluster is unavailable
Quotas and auditing

Power-on calls are subject to the same limits as the UI: the plan's maximum number of Live Apps, the organization's worker and CPU/GPU hour quotas, and the worker plan capacity. A power-on that would exceed capacity returns 406 instead of starting the app.

Actions performed with a token are recorded like any other action and appear in the app's log (View logs button). They are attributed to the anonymous user, which is how API-driven starts are told apart from starts by a person.