Deploy notebook servers or apps¶

marimo can be deployed as an "edit" server for creating, running, and editing notebooks, or an app server for serving read-only web apps. For convenience, you can use our pre-built containers.

Sharing notebooks on the public web

To share notebooks on the public web without managing infrastructure, try molab, our free cloud-hosted notebook environment

Notebook servers¶

Deploy an edit server (marimo edit) to let users create and edit notebooks on a remote instance.

Guide	Description
JupyterHub	Run marimo inside JupyterHub with our JupyterLab extension
Kubernetes	Deploy on Kubernetes
SkyPilot	Deploy on cloud VMs with SkyPilot
Slurm	Run on HPC clusters with Slurm

You can also deploy an edit server with ssh port forwarding using marimo edit --headless.

Apps¶

Deploy notebooks as read-only web apps (marimo run) or embed them in other applications.

Guide	Description
FastAPI	Programmatically run marimo apps as part of ASGI applications
Authentication	Authentication and security
Docker	Deploy with Docker
HuggingFace	Deploy to Hugging Face Spaces
Railway	Deploy to Railway
nginx	Deploy behind nginx

Health and status endpoints¶

The following endpoints may be useful when deploying your application:

/health - A health check endpoint that returns a 200 status code if the application is running as expected
/healthz - Same as above, just a different name for easier integration with cloud providers
/api/status - A status endpoint that returns a JSON object with the status of the server

Configuration¶

If you would like to deploy your application at a subpath, you can set the --base-url flag when running your application.

marimo run app.py --base-url /subpath

Deploying without WebSockets (experimental)¶

marimo streams kernel messages to the browser over a WebSocket by default. Some proxies and hosting services handle WebSockets poorly or not at all; for these deployments, you can switch the kernel connection to server-sent events (SSE) over plain HTTP with the MARIMO_SERVER_TRANSPORT environment variable:

MARIMO_SERVER_TRANSPORT=sse marimo run app.py

This setting is experimental. Keep in mind:

The terminal and language servers (LSP) in marimo edit still require WebSockets and are unaffected by this setting.
Real-time collaboration (rtc_v2) requires WebSockets and is disabled when using SSE.
Make sure proxies do not buffer the /sse endpoint's text/event-stream responses (marimo sends Cache-Control: no-transform and X-Accel-Buffering: no headers, and a keep-alive comment every 20 seconds).
Browsers cap concurrent HTTP/1.1 connections per origin (typically 6), so prefer serving over HTTP/2 when many notebook tabs may be open at once.

Including code in your application¶

By default, marimo run does not send your notebook's source code to browser clients, so viewers cannot read it from the browser (including through dev tools).

If you want to expose the code to viewers, pass the --include-code flag:

marimo run app.py --include-code

Redirecting standard output to the browser¶

By default, Marimo doesn't send standard output (stdout) to the browser, but for debugging purposes you can enable this with --redirect-console-to-browser:

marimo run app.py --redirect-console-to-browser

Showing error tracebacks in the browser¶

By default, Marimo redacts error tracebacks in the browser for security reasons, but you can enable showing full tracebacks with --show-tracebacks:

marimo run app.py --show-tracebacks