Skip to main content



This feature is not yet accessible in Naas Lab for Community tier. Please book a meeting with us if you are interested to try it out.

Naas Space is a service that enables Naas users to deploy data products and services in dedicated serverless containers from Naas Lab. This specification outlines the technical details and requirements of the Naas Space service.

Shiping Data & AI Products in Serverless Containers

The purpose of this service is to enable Naas users to deploy their own data products/services outside of their JupyterLab environment. This service plays a crucial role in facilitating deployment for several reasons:

  • Scalability: Deploying a data product/service outside of JupyterLab allows users to leverage the full potential of cloud resources for scaling their applications. This ensures that their solutions can accommodate larger datasets and increased user traffic without being limited by the constraints of their local JupyterLab environment.

  • Flexibility: Building a serverless container service provides users with the flexibility to choose their preferred technology stack (such as Docker, Plotly-Dash, React application, or FastAPI) for deploying their data products/services. This empowers users to select the best tools for their specific use case and requirements.

  • Version Control and Collaboration: Integrating the project with GitHub enables users to take advantage of version control and collaboration features. This not only helps in tracking changes and maintaining a history of code revisions but also allows multiple team members to work on the project simultaneously.

  • Automated Deployment: By generating continuous integration (CI) configurations (e.g., using GitHub Actions), the serverless container service simplifies the deployment process. This allows users to automatically build, test, and deploy their data products/services upon pushing changes to the GitHub repository, reducing the risk of human error and streamlining the development workflow.

  • Professionalism and Accessibility: Deploying a data product/service outside of JupyterLab provides a more professional presentation of the user's work. This allows stakeholders, clients, or other users to access the data product/service through a dedicated URL without the need for JupyterLab, making it more accessible and easier to share.

Hosting/Domain Definition

Users can access the Naas Space feature under the same namespace: [dashboard] If a user is in Enterprise mode, they can define their own domain, such as [dashboard] or create a specified subdomain [dashboard].[client] to be isolated. The advantage of using Enterprise mode is to have a secure namespace and be able to name data products as desired.

Supported Data Products

The Naas Space Job supports various data products and services, including:

  • Dashboards (first iteration focus on Plotly)
  • Docker containers
  • Static websites
  • APIs
  • Models
  • Alerting systems
  • Services (to be discussed)

As of now, the Naas Space job supports all data products and services that can be deployed using Docker containers. In the future, we plan on expanding the list of supported shipping mechanisms to include a broader range of data leveraging technologies.

Get started via the naas-python library using this guide.

Space Framework concepts

Spaces have been designed to be as simple as possible to use. The framework is based on the following concepts:

  • Docker container: a docker container can be shipping any kind of data product or service. It is a containerized environment that can be deployed on any cloud provider.
  • Registry: the registry is the place where the container is stored/uploaded and serves as a repository, such as Docker Hub or If the user opts for the Enterprise mode, the registry will be hosted on the client's cloud provider.
  • Kubernetes: Kubernetes is the technology used to deploy the container and manage the resources, responsible for scaling, monitoring, and managing the container.
  • Knative: Knative is a Kubernetes-based platform to build, deploy, and manage modern serverless workloads. It provides a set of middleware components that are essential to build modern, source-centric, and container-based applications that can run anywhere: on premises, in the cloud, or even in a third-party data center.

Below is a basic diagram of the Naas Space framework and how the different components interact with each other:


The Naas Space service is a versatile solution for efficiently managing the deployment of data products and services. It's powered by an API that enables the creation of low-code formulas tailored to the unique characteristics of data products. These low-code formulas simplify the process of deploying data products, offering users an intuitive interface for streamlined operations.

To interact with Naas's primary service for scheduling spaces, you have the option to use the `naas-python`` library. This library seamlessly integrates with Naas Lab's authentication mechanism, providing users with two key modes of interaction: a Command Line Interface (CLI) and a Python API. For installation instructions, please refer to the documentation.

Naas Space offers several methods to interact with its API, including create, list, delete, update, and add. These methods are accessible through both the CLI and the Python API, above all, we present the user with a straightforward .add formula that can be used to deploy a containerized application and comprehends all the parameters needed to do so.

Throughput the following section, we will delve into the practical use of the naas-python library for deploying a containerized application. This will entail a comprehensive breakdown of each parameter, accompanied by a clear and straightforward step-by-step example for your guidance.

The method is the primary method for deploying a containerized application. It takes in a set of parameters that define the deployment configuration and returns a URL that can be used to access the deployed application.

SDK Example

from naas_python import space


Argument reference

The following arguments are supported:

  • space_name: The name of the space. This is used to generate the URL for accessing the deployed application. The URL will be in the format: [space_name] For example, if the space name is "my-space", the URL will be:
  • space_type: The type of the space. This is used to determine the type of container that will be deployed. Currently, the only supported type is "docker".
  • dockerfile_path: The path to the Dockerfile. This is used to build the Docker image that will be deployed.
  • docker_context: The path to the Docker context. This is used to build the Docker image that will be deployed.
  • image_tag: The tag for the Docker image. This is used to build the Docker image that will be deployed.
  • container_port: The port for the Space container. This is used to determine the port that will be exposed by the container.
  • generate_ci: A boolean value indicating whether or not to generate a CI/CD configuration. This is used to determine whether or not to generate a CI/CD configuration for the container.
  • skip_registry: A boolean value indicating whether or not to skip creating a Docker registry. This is used to determine whether or not to create a Docker registry for the container. If not passed, the image parameter must be passed with a valid registry name.
  • registry_name: The name of the registry. This is used to determine the name of the Docker registry that will be created.
  • ci_type: The type of CI/CD configuration to generate. This is used to determine the type of CI/CD configuration that will be generated.
  • image: The image of the space. This is used to determine the image that will be deployed. The value must be in the format: [registry_name]/[image_name]:[image_tag]. For example, "my-registry/my-image:latest".
  • cpu: The CPU utilization for the Space container. This is used to determine the CPU utilization for the container. The value must be in the format: [number][unit]. For example, "2" or "512m".
  • memory: The memory utilization for the Space container. This is used to determine the memory utilization for the container. The value must be in the format: [number][unit]. For example, "2Gi" or "512Mi".

Naas Space add diagram flow

The low-code formula will also include other data products and services, such as static websites, APIs, and AI/ML engines.

The formula is yet to be finalized.


Naas Space supports basic authentication in its first iteration. Advanced authentication using OAuth2 providers will be implemented for Enterprise users to share data products securely.


Once authenticated a ~/.naas/credentials file will be created in the user home directory. This file will contain the user's credentials and will be used to authenticate the user for subsequent requests.


Service deployment will be automated using Knative. Users can upload their data products to Naas Space by providing an archive containing their code and dependencies. Naas Space will then handle the deployment and management of the containerized data product.

For a contextualized example, checkout our example repository here. Here we showcase how to deploy a simple HTML page into a flask API server that will be deployed and managed by a Naas Space container.


Naas Space provides a simple and efficient way for Naas users to deploy their data products and services. The service supports various data products and services, including dashboards, static websites, APIs, models, and alerting systems. Naas Space will automate the deployment process and provide an easy-to-use interface for users to deploy their data products.