Skip to main content

Create a template

tip

🚧 You will soon be able to submit your templates to the NodeOps Cloud Marketplace.

🌟 Status: A selection of templates are available

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 specifies:

  • 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 infrastrucure blueprint or playbook: ensuring consistent deployment configurations for users.

SpecificationDescriptionExampleAllowable Values
Docker ImageSpecifies the public Docker image used for deployment.nginx:latestValid Docker image tags (name:tag)
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

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 during NodeOps Network Testnet; high availability storage options will be available in future updates.
warning
  1. Privileged access is not allowed.
  2. All Linux capabilities will be dropped.
  3. Templates will run with userid: 65535 (non-root).
  4. No TCP/UDP ports will be exposed during this stage.
  5. All container images must be publicly accessible.
  6. HTTP/S services will be 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 as part of testnet.
  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.

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 nginx template​

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

metadata:
  name: template
schema:
  version: "0.1"
services:
  image: nginx:latest
  imagePullPolicy: "Always"
  command: "/usr/sbin/nginx"
  args:
    - "-g"
    - "daemon off;"
  port:
    - containerPort: 80
      name: http
      protocol: "TCP"
      expose: true
    - containerPort: 443
      name: https
      protocol: "TCP"
      expose: false
  env:
    APP_ENV: "production"
    DEBUG_MODE: "false"
  resources:
    idle:
      cpu: "100m"
      memory: "256Mi"
    peak:
      cpu: "500m"
      memory: "1024Mi"

nginx required fields explained​

Version​

Defines the version of the template specification. Use "0.1".

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 Jupiter notebook​

metadata:
  name: template
version: '0.1'
services:
  jupiter:
    image: jupyter/base-notebook
    resources:
      idle:
        cpu: 200m
        memory: 400Mi

Example Protocol Node template​

metadata:
  name: template
version: '0.1'
services:
  - validator:
      image: elixirprotocol/validator:latest 
      imagePullPolicy: Always
      args: []
      port:
        - containerPort: 80
          name: http
          protocol: TCP
          expose: true
      env: 
        - value: "{{ .USER_INPUT_1 }}"
          default: development
      resources:
        idle:
          cpu: 100m
          memory: 8000Mi

FAQ​

How are template submissions compensated?​

Template compensations are bounty based.

Can a template expose an application to the internet?​

Yes. If you set expose: true for a port in your template, the application will be accessible externally.

Example:

ports:
  - containerPort: 8888
    protocol: TCP
    expose: true

This means users can access the application via a generated URL after deployment.

Service limitation

Only one service per template can be exposed externally.

How can I allow users to provide input values in my template?​

You can use placeholders ({{.ENV}}) in your template to allow users to provide values during deployment.

Example:

env:
  - name: APP_ENV
    value: "{{.ENV}}"

When a user deploys this template, they will be prompted to provide a value for APP_ENV.

Use this approach for any configuration that varies per deployment such as:

  • API keys
  • Wallet addresses
  • Database credentials

What resources can I define in my template?​

You can specify CPU and memory allocations under resourceUsage.

Example:

resourceUsage:
  idle:
    cpu: 200 # 0.2 CPU cores
    memory: 400 # 400MB RAM

This defines the minimum required resources when the application is idle.

Are there template upgrade constraints?​

Yes, upgrades don't include:

  • Adding new services
  • Modifying resource allocations for existing services

Such amendments require resubmission of a template as a new entitiy.

Can users modify my template after deploying it?​

No, users can't modify the template itself after deployment. However, they can provide values for placeholders ({{.ENV}}) during deployment.

How do I price my template?​

The pricing is linked to resource usage (CPU & memory). You can define minimum resource requirements in your template, which will determine the cost.

What happens if my template uses a private Docker image?​

Your template must use a public Docker image. Private images cannot be pulled by users. If you are using the Private Docker Images you should provide us with the credentials to access those images.

What happens if my template does not specify a public port?​

If expose: false or no port is defined, the application will run internally but will not be accessible from the internet. This is useful for background services.

Can I specify default environment variables in my template?​

Yes, you can define both static and user-provided environment variables.

Example:

env:
  - name: STATIC_ENV
    value: "fixed_value"
  - name: DYNAMIC_ENV
    value: "{{.USER_INPUT}}"
  • STATIC_ENV has a fixed value
  • DYNAMIC_ENV will be set by the user during deployment

What happens if a user provides invalid values for placeholders?​

The system will validate user inputs before deployment. If a required value is missing or invalid, the user will be asked to correct it.

Can I provide documentation with my template?​

Yes! It’s recommended to include a README or metadata explaining:

  • What the template does
  • Required user inputs
  • Expected behavior after deployment

This improves usability for those deploying your template.

How can I test my template before publishing it?​

Before publishing your template, you should deploy and test it in the Marketplace to ensure:

  • It runs correctly without errors
  • Placeholder variables ({{.ENV}}) are correctly substituted during deployment
  • Resource constraints (CPU, memory) are within allowed limits and function as expected
tip

Additionally, a playground for contributors will soon be available, allowing you to conduct thorough testing before publishing your template. This feature will help you validate your template in a controlled environment before making it publicly available. 🚀

What should I do if my template fails to deploy?​

  • Check if the Docker image is publicly accessible
  • Verify placeholder variables ({{.ENV}}) are correctly defined
  • Ensure resource constraints (CPU, memory) are within allowed limits

If issues persist, review logs or update your template.

Can I remove my template after publishing?​

Yes, you can remove or archive your template from the Marketplace if it's no longer needed.

What next?​