# Container Services

> **📝 Note**: Containers and the medium/GPU pool are currently in private preview. Please contact [Support](https://support.singlestore.com) for more information

SingleStore’s Aura Container Service (SingleStore Aura service, also referred to as "Managed Container Service") is a serverless platform designed to provide instant access to pre-warmed containers for running custom applications with minimal latency. While initially developed to support Jupyter Notebooks, the platform is designed to execute any containerized application across supported hardware configurations.

## Key Features

* **Instant Container Availability**: The platform maintains a pool of pre-warmed containers, enabling sub-second container acquisition times for your applications. This eliminates the traditional wait times associated with container startup and initialization.
* **Enhanced Security**: The platform implements the [gVisor](https://gvisor.dev/) container runtime for robust security isolation, allowing you to safely execute untrusted code, LLM-generated content, or third-party applications without compromising the host system.
* **GPU Support**: Pre-configured container images come with NVIDIA drivers pre-installed, making it seamless to run GPU-accelerated workloads without additional setup.
* **Simplified Developer Experience**: The platform abstracts away the complexity of Docker and Kubernetes management and handles all container orchestration automatically, allowing developers to focus on their code rather than infrastructure concerns.

## How It Works

## Container Pool Management

The platform automatically maintains and manages a pool of warm containers, ensuring immediate availability when requested.

## Streamlined Workflow

Traditional container deployment typically involves:

1. Spinning up a new container

2. Configuring the environment

3. Installing required dependencies

4. Starting application services

With the Aura Container Service, this process is simplified to:

1. Request a container

2. Connect to a pre-configured environment

3. Begin working immediately

## Container Sizing and Node Type

| **Node**                             | **Container**                                 |
| ------------------------------------ | --------------------------------------------- |
| CPU Pool                             | Small(1750m vCPU, 14 GB RAM, 40 GB)           |
| Medium(3750m vCPU, 27 GB RAM, 40 GB) |                                               |
| GPU Pool                             | GPU - T4(1 GPU, 6500m vCPU, 27 GB RAM, 40 GB) |

## Rate Limits

To prevent abuse, either accidental or intentional, SingleStore enforces limits on the number of containers that can be created in an organization, which can be increased upon request.

By default, an organization can have up to 50 active sessions and can create up to 20 containers per minute.

## Session Limits

The session limits for different container service workloads are:

| **Workload Type**     | **Idle Timeout (Minimum)** | **Idle Timeout (Maximum)** | **Long Code Execution Limit** |
| --------------------- | -------------------------- | -------------------------- | ----------------------------- |
| Interactive Notebooks | 15 minutes (Default)       | 4 hours                    | 1 hour                        |
| Dashboards            | 15 minutes (Default)       | No Timeout                 | 1 hour                        |
| Cloud Functions       | 15 minutes (Default)       | No Timeout                 | 1 hour                        |
| Python UDFs           | 15 minutes (Default)       | No Timeout                 | 1 hour                        |

Idle Timeout can be configured while creating or updating the workload instance. Once the timeout limit is reached, the system automatically terminates the workload session and deletes any unsaved data (state/variables/files).

Interactive notebooks allow a single active session per user with each session having a maximum lifetime of 8 hours.

Organization-level workloads such as Dashboards, Cloud Functions, and Python UDFs allow only one active session at a time, and that session is shared across all users.

## Session Persistence and State Management

Workload sessions can run indefinitely when no idle timeout is configured or when activity remains within the configured limits.

However, workloads must not rely on in-memory state or stateful connections. The system may move a session across multiple containers during its lifetime. As a result, in-memory state can be lost at any time and stateful protocols or long-lived connections are not guaranteed to persist.

## In this section

* [Notebooks](https://docs.singlestore.com/cloud/container-services/notebooks.md)
* [Scheduled Jobs](https://docs.singlestore.com/cloud/container-services/scheduled-jobs.md)
* [Dashboard Apps](https://docs.singlestore.com/cloud/container-services/dashboard-apps.md)
* [Cloud Functions](https://docs.singlestore.com/cloud/container-services/cloud-functions.md)
* [Container App API Keys](https://docs.singlestore.com/cloud/container-services/container-app-api-keys.md)
* [Container Services RBAC](https://docs.singlestore.com/cloud/container-services/container-services-rbac.md)
* [Python UDFs](https://docs.singlestore.com/cloud/container-services/python-udfs.md)

***

Modified at: December 19, 2025

Source: [/cloud/container-services/](https://docs.singlestore.com/cloud/container-services/)

(An index of the documentation is available at /llms.txt)