App Specifications

App Specifications & Pricing

Every Flux App is defined by a specification document — a JSON object that describes everything the network needs to deploy and run your container. Understanding the specification format, resource tiers, and pricing model is essential for optimizing your deployment costs while ensuring your application has the resources it needs to perform well.

Resource Tiers in Detail

Flux defines three resource tiers that correspond directly to the three FluxNode hardware classes. Your app is assigned to the lowest tier that can accommodate all of its resource requirements. If even one resource dimension (CPU, RAM, or storage) exceeds a tier's limit, the app is bumped to the next tier.

Cumulus Tier

Cumulus is the entry-level tier, ideal for lightweight applications such as static websites, simple APIs, bots, monitoring dashboards, and small databases. Cumulus nodes are the most abundant on the network, so deployment is fast and availability is high. This tier offers the lowest cost per month.

Nimbus Tier

Nimbus suits medium-weight workloads: application servers with moderate traffic, medium-sized databases (PostgreSQL, MongoDB), blockchain light nodes, content management systems, and backend services that need more memory or processing power. Nimbus nodes are well-provisioned machines, typically with 8+ CPU cores and 32+ GB of total RAM.

Stratus Tier

Stratus is the highest performance tier, designed for resource-intensive applications: blockchain full nodes with large chain data, AI model inference, big databases, high-traffic web applications, and computation-heavy services. Stratus nodes are the most powerful machines on the network, typically featuring 16+ CPU cores, 64+ GB of RAM, and fast NVMe storage.

How Pricing Works

Flux App pricing is calculated using a deterministic formula based on the resources you allocate. The cost scales linearly with each resource dimension and is multiplied by the number of instances. The general formula is:

Monthly Cost (FLUX) = (cpu_cost + ram_cost + hdd_cost) × instances

Where:
  cpu_cost = cpu_cores × base_cpu_rate_for_tier
  ram_cost = ram_mb × base_ram_rate_for_tier
  hdd_cost = hdd_gb × base_hdd_rate_for_tier

Base rates are adjusted dynamically based on FLUX price
to maintain relatively stable USD-equivalent costs.

As an approximate guide, here are typical monthly costs for common configurations (these fluctuate with FLUX token price):

The App Specification Format

The full app specification is a JSON object submitted to the Flux blockchain. Here is a complete annotated example covering every available field:

{
  "name": "my-production-api",
  "description": "Production REST API for my web application",
  "owner": "1ZELID_ADDRESS_HERE",
  "compose": [
    {
      "name": "api-server",
      "description": "Express.js API server",
      "repotag": "myuser/my-api:v2.1.0",
      "ports": [31000],
      "domains": ["api.myapp.com"],
      "environmentParameters": [
        "NODE_ENV=production",
        "DATABASE_URL=mongodb://db-host:27017/mydb",
        "REDIS_URL=redis://cache-host:6379",
        "LOG_LEVEL=warn"
      ],
      "commands": ["--max-old-space-size=1024"],
      "containerPorts": [3000],
      "containerData": "/app/data",
      "cpu": 1,
      "ram": 2048,
      "hdd": 10,
      "tipiered": false,
      "secrets": "",
      "repoauth": ""
    }
  ],
  "instances": 3,
  "contacts": ["admin@myapp.com"],
  "geolocation": ["na", "eu"]
}

Field Reference

Geolocation Options

The geolocation field lets you constrain which geographic regions your app instances are deployed in. This is useful for data sovereignty requirements or for optimizing latency to a specific user base. Available region codes include:

• •"na" — North America
• •"eu" — Europe
• •"as" — Asia
• •"oc" — Oceania
• •"sa" — South America
• •"af" — Africa

Persistent Storage Considerations

Data written to the path specified in containerData is persisted across container restarts on the same node. However, if your app instance is migrated to a different node (due to node failure or network rebalancing), persistent data does not migrate automatically. For databases and stateful applications, implement your own replication strategy or use external backup solutions. Each instance maintains its own independent persistent volume — there is no shared filesystem across instances.

Resource Optimization Tips

• •Start small and scale up. Deploy with minimal resources first, monitor actual usage via the dashboard, then increase allocations only if needed.
• •Use Alpine-based images. Smaller Docker images deploy faster and consume less storage. Prefer node:20-alpine over node:20, python:3.12-slim over python:3.12.
• •Minimize persistent storage. Only request HDD space you actually need. Store large assets in external object storage (S3-compatible services) rather than local disk.
• •Right-size your RAM. Over-allocating RAM increases costs without benefit. Profile your application locally with docker stats before choosing a RAM value.
• •Consider the tier boundary. If you need 0.6 CPU cores, you are pushed to Nimbus tier. If you can optimize to stay at 0.5 cores, you save significantly by staying on Cumulus.
• •Use multi-stage Docker builds. Keep your final image lean by using build stages to exclude build tools, dev dependencies, and source code from the production image.

Understanding the app specification format and pricing model allows you to make informed decisions about resource allocation. The goal is to allocate enough resources for reliable performance while staying in the most cost-effective tier for your workload.