Skip to main content

Template schemas

Define services in a template​

NodeOps Network's Marketplace Infrastructure is defined and provisioned via a viable YAML file known as a template.

This YAML file defines how an application should run within NodeOps Network's Cloud Infrastructure. It can be used to specify:

  • The public Docker image to be used
  • Resource allocation (CPU, memory)
  • Environment variables
  • Whether the application should be exposed to the internet

A template acts as an infrastructure blueprint or playbook: ensuring consistent deployment configurations for users.

Template specification overview​

SpecificationDescriptionExampleAllowable Values
Docker ImageSpecifies the public Docker image used for deployment.nginx:latestValid Docker image tags (name:tag) for arch amd64
Resource AllocationDefines cpu and memory resources allocated to the application.cpu: "500m" memory: "128Mi"CPU (m for milli-cores), Memory (Mi)
Environment VariablesConfigures environment variables, including placeholders and defaults.env: - name: APP_ENV value: "{{.ENV}}" default: developmentDynamic ({{.ENV}}), Static values
Internet ExposureIndicates whether the application should be accessible publicly.expose: truetrue, false

The template structure is versatile to accommodate all your use cases, use the drop down to learn more:

Show me the YAML definition
name: template.yaml
type: object
required:
  - version
  - services
description: Schema for the YAML template file used to manage Cloud Compute infrastructure.
properties:
  version:
    type: float
    example: 0.1
    description: Defines the version of the template specification. Must start at 0.1.
  services:
    type: object
    description: List of services to be deployed.
    properties:
      image:
        type: string
        required: true
        description: Publicly-accessible Docker/container image for the service.
      imagePullPolicy:
        type: string
        required: false
        enum: ["Always", "IfNotPresent", "Never"]
        description: Defines when to pull the Docker image for the service.
      command:
        type: string
        required: false
        description: The command to execute when the service starts.
      args:
        type: array
        required: false
        description: Arguments to pass to the command for the service.
        items:
          type: string
      ports:
        type: array
        required: true
        description: Port definitions for the service.
        items:
          type: object
          required:
            - containerPort
            - expose
          properties:
            containerPort:
              type: integer
              required: true
              description: Application port.
            protocol:
              type: string
              required: false
              enum: ["TCP", "UDP"]
              description: The protocol used by the service.
            expose:
              type: boolean
              required: false
              description: Boolean value indicating if the port should be exposed for the service.
              example: false
          env:
            type: array
            required: false
            description: Predefined environment variables for runtime.
            items:
              type: object
              required:
                - name
                - value
              properties:
                name:
                  type: string
                  required: true
                  description: Name of the environment variable.
                value:
                  type: string
                  required: true
                  description: The value of the environment variable (static or dynamic).
                default:
                  type: string 
                  required: false
                  description: Sets a fallback value to apply.
          resourceUsage:
            type: object
            required: true
            description: Specifies the resources required by the service.
            properties:
              idle:
                type: object
                required: true
                description: Minimum requirements.
                properties:
                  cpu:
                    type: integer
                    required: true
                    description: CPU unit in millicores.
                  memory:
                    type: integer
                    required: true
                    description: Memory unit in megabytes.

See examples and further details

Operational constraints​

  1. All services in the template run under a single pod with same network namespace.

This allows all the services to connect to each other over localhost.

  1. Persistent storage is not guaranteed on NodeOps Network; high availability storage options will be available in future updates.
warning
  1. Privileged access is not allowed.
  2. All Linux capabilities are dropped.
  3. Templates run with userid: 65535 (non-root).
  4. No TCP/UDP ports are exposed during this stage.
  5. All container images must be publicly accessible.
  6. HTTP/S services are exposed behind a Cloudflare proxy under AtlasNetwork.app.

Template constraints​

To ensure fair resource usage, the following constraints apply:

Template constraints
  1. Maximum of 5 services.
  2. Only one service per template can be exposed to the public.
  3. Only 1 persistent volume is allowed.
  4. The total resource usage is limited to 4 Compute Units (CUs)

calculated as: CU = max(total CPU, total Memory)

  1. Upon template interruption, all services will be restarted as part of a single pod with multiple containers.

Template update constraints​

You can update descriptions, documentation, and new versions of your Docker Image.

Learn how.

However:

  • You can't modify a template's existing service resource allocations
  • You can't add new services in an upgrade to a template

Example templates​

Example Jupiter notebook​

version: 0.1
services:
  jupiter:
    image: jupyter/base-notebook
    resourceUsage:
      idle:
        cpu: 200
        memory: 400

Example nginx template​

For example, to configure services such as nginx, the YAML would abide by the following properties:

  version: 0.1
  services:
    nginx:
      image: nginx:latest
      args:
        - '-g'
        - 'daemon off;'
      imagePullPolicy: "Always"
      ports:
        - containerPort: 80
          protocol: TCP
          expose: true
        - containerPort: 443
          protocol: TCP
          expose: false
      env:
        - name: APP_ENV
          value: production
        - name: DEBUG_MODE
          value: 'false'
      resourceUsage:
        idle:
          cpu: 100
          memory: 256

nginx required fields explained​

Version​

Defines the version of the template specification. Use 0.1 as the baseline.

Services​

Each service definition requires the following fields:

  • image: Publicly accessible Docker/container image for the service
  • port: Port/s inside the container where the application listens/serves traffic
  • env: Predefined environment variables for the service runtime
  • resourceUsage: Specifies the resources required by the service

Example Protocol Node template​

version: 0.1
services:
  validator:
    image: elixirprotocol/validator:latest 
    imagePullPolicy: Always
    args: []
    ports:
      - containerPort: 80
        protocol: TCP
        expose: true
    env: 
      - name: USER_DEFINED
        value: "{{ .USER_INPUT_1 }}"
        default: development
    resourceUsage:
      idle:
        cpu: 100
        memory: 4000

Gotchas​

Architecture tags​

Docker images inherit the host’s architecture unless explicitly set. For example, building on an Apple M-series Mac defaults to linux/arm64 even if the image is intended for amd64.

  • Check the manifest: Always run docker manifest inspect <image> to confirm the declared platform before pushing.
  • Be explicit: Use --platform linux/amd64 with docker buildx to avoid incorrect tagging.

What next?​