Sign inTry Free

Container Services

On this page

Note

Containers and the medium/GPU pool are currently in private preview. Please contact Support 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 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

Last modified: December 19, 2025

Was this article helpful?

On this page

Was this article helpful?

Verification instructions

Note: You must install cosign to verify the authenticity of the SingleStore file.

Use the following steps to verify the authenticity of singlestoredb-server, singlestoredb-toolbox, singlestoredb-studio, and singlestore-client SingleStore files that have been downloaded.

You may perform the following steps on any computer that can run cosign, such as the main deployment host of the cluster.

  1. (Optional) Run the following command to view the associated signature files.

    curl undefined

  2. Download the signature file from the SingleStore release server.

    • Option 1: Click the Download Signature button next to the SingleStore file.

    • Option 2: Copy and paste the following URL into the address bar of your browser and save the signature file.

    • Option 3: Run the following command to download the signature file.

      curl -O undefined

  3. After the signature file has been downloaded, run the following command to verify the authenticity of the SingleStore file.

    echo -n undefined |
        cosign verify-blob --certificate-oidc-issuer https://oidc.eks.us-east-1.amazonaws.com/id/CCDCDBA1379A5596AB5B2E46DCA385BC \
          --certificate-identity https://kubernetes.io/namespaces/freya-production/serviceaccounts/job-worker \
          --bundle undefined \
          --new-bundle-format -
    Verified OK

Try Out This Notebook to See What’s Possible in SingleStore

Get access to other groundbreaking datasets and engage with our community for expert advice.

Sign UpLog In