Create a template
🚧 You will soon be able to submit your templates to the NodeOps Cloud Marketplace.
- Testnet
- Mainnet
🌟 Status: A selection of templates are available
🚧 Status: Coming soon
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.
Specification | Description | Example | Allowable Values |
---|---|---|---|
Docker Image | Specifies the public Docker image used for deployment. | nginx:latest | Valid Docker image tags (name:tag ) |
Resource Allocation | Defines cpu and memory resources allocated to the application. | cpu: "500m" memory: "128Mi" | CPU (m for milli-cores), Memory (Mi ) |
Environment Variables | Configures environment variables, including placeholders and defaults. | env: - name: APP_ENV value: "{{.ENV}}" default: development | Dynamic ({{.ENV}} ), Static values |
Internet Exposure | Indicates whether the application should be accessible publicly. | expose: true | true , false |
Operational constraints​
- 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.
- Persistent storage is not guaranteed during NodeOps Network Testnet; high availability storage options will be available in future updates.
- Avoid storing sensitive data (e.g., private keys) on disk
- Avoid relying on persistent storage on Testnet
- Privileged access is not allowed.
- All Linux capabilities will be dropped.
- Templates will run with userid: 65535 (non-root).
- No TCP/UDP ports will be exposed during this stage.
- All container images must be publicly accessible.
- HTTP/S services will be exposed behind a Cloudflare proxy under AtlasNetwork.app.
Template constraints​
To ensure fair resource usage, the following constraints apply:
- Maximum of 5 services as part of testnet.
- Only one service per template can be exposed to the public.
- Only 1 persistent volume is allowed.
- The total resource usage is limited to 4 Compute Units (CUs)
calculated as: CU = max(total CPU, total Memory)
- 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:
- nginx example
- nginx JSON Schema
- nginx YAML definition
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"
name: template.yaml
type: object
required:
- version
- services
description: Schema for the YAML template file used to manage cloud compute infrastructure.
properties:
version:
type: string
enum: [0.1]
description: Defines the version of the template specification.
services:
type: array
description: List of services to be deployed.
items:
type: object
properties:
nginx:
type: object
required:
- image
- port
- env
- resourceUsage
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
port:
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.
name:
type: string
required: false
description: A descriptive name of the port.
protocol:
type: string
required: false
enum: ["TCP", "UDP"]
description: The protocol used by the service.
expose:
type: boolean
required: true
description: Boolean value indicating if the port should be exposed for the service.
example: false
env:
type: array
required: true
description: Predefined environment variables for the nginx service 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 (Either static or dynamic).
resourceUsage:
type: object
required: true
description: Specifies the resources required by the nginx service.
properties:
idle:
type: object
required: true
description: Minimum requirements.
properties:
cpu:
type: number
required: true
description: CPU unit in millicores.
memory:
type: string
required: true
description: Memory unit in megabytes.
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​
- Jupiter Notebook example
- Jupiter Notebook Schema
- YAML definition
metadata:
name: template
version: '0.1'
services:
jupiter:
image: jupyter/base-notebook
resources:
idle:
cpu: 200m
memory: 400Mi
name: template.yaml
type: object
required:
- version
- services
properties:
version:
type: string
enum: ['0.1']
description: Defines the version of the template specification.
services:
type: object
properties:
jupiter:
type: object
required:
- image
- resourceUsage
properties:
image:
type: string
description: Publicly-accessible Docker/container image for the service.
default: jupyter/base-notebook
resourceUsage:
type: object
properties:
idle:
type: object
required:
- cpu
- memory
properties:
cpu:
type: number
description: CPU unit in millicores.
default: 200
memory:
type: number
description: Memory unit in megabytes.
default: 400
Example Protocol Node template​
- Elixir Node example
- Elixir Node Schema
- Elixir NodeYAML definition
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
🚧 WIP example:
name: template.yaml
type: object
required:
- version
- services
properties:
version:
type: string
enum: ['0.1']
description: Defines the version of the template specification.
services:
type: array
description: List of services to be deployed.
items:
type: object
properties:
validator:
type: object
required:
- image
- imagePullPolicy
- port
- env
- resourceUsage
properties:
image:
type: string
description: Publicly-accessible Docker/container image for the service.
default: "elixirprotocol/validator:latest"
imagePullPolicy:
type: string
enum: ["Always", "IfNotPresent", "Never"]
description: Defines when to pull the Docker image for the service.
default: "Always"
args:
type: array
description: Arguments to pass to the command for the service.
items:
type: string
default: []
port:
type: array
description: Port definitions for the service.
items:
type: object
required:
- containerPort
- name
- protocol
- expose
properties:
containerPort:
type: integer
description: Application port.
default: 80
name:
type: string
description: A descriptive name of the port.
default: "http"
protocol:
type: string
enum: ["TCP", "UDP"]
description: The protocol used by the service.
default: "TCP"
expose:
type: boolean
description: Boolean value indicating if the port should be exposed for the service.
default: true
env:
type: array
description: Predefined environment variables for the nginx service runtime.
items:
type: object
required:
- name
- value
properties:
name:
type: string
description: Name of the environment variable.
default: "ENV"
value:
type: string
description: User-provided value of the environment variable (Either static or dynamic).
default: "{{ .USER_INPUT_1 }}"
default:
type: string
description: Default setting for the environment variable.
default: "development"
resourceUsage:
type: object
required:
- idle
description: Specifies the resources required by the nginx service.
properties:
idle:
type: object
required:
- cpu
- memory
properties:
cpu:
type: number
description: CPU unit in cores.
default: 0.1
memory:
type: string
description: Memory unit.
default: "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.
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
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?​
- Learn more about the benefits of "Infrastructure as Configuration"
- Scan your template for vulnerabilities