Deployments & Lifecycle

Master the complete deployment lifecycle on Akash Network.

A deployment is the fundamental unit of work on Akash - it represents your application, its resource requirements, and the agreement with a provider to run it. Understanding the deployment lifecycle is key to successfully using Akash.

What is a Deployment?

A deployment is a request for compute resources on Akash Network. When you create a deployment:

1. You describe what you want to run (containers, resources, ports)
2. The deployment is posted to the blockchain
3. An order is created on the marketplace
4. Providers bid to host your deployment
5. You accept a bid and create a lease
6. Your application runs on the provider’s infrastructure

Key Components

Deployment

The deployment is your application specification:

• Services - What containers to run
• Resources - CPU, memory, storage, GPU requirements
• Pricing - Maximum you’re willing to pay
• Placement - Optional requirements (location, attributes)

Stored on: Akash blockchain
Identified by: Deployment Sequence (DSEQ) - unique number per account

Order

When you create a deployment, an order opens on the marketplace:

• Advertises your resource needs
• Includes pricing and placement requirements
• Stays open for ~5 minutes
• Providers submit bids during this window

Stored on: Akash blockchain
Identified by: DSEQ + Group Sequence (GSEQ) + Order Sequence (OSEQ)

Bid

A bid is a provider’s offer to host your deployment:

• Specifies the price they’ll charge
• Includes provider information and attributes
• Must be at or below your maximum price
• Can be accepted to create a lease

Stored on: Akash blockchain
Identified by: DSEQ + GSEQ + OSEQ + Provider Address

Lease

A lease is the active agreement between you and a provider:

• Locks in pricing
• Reserves resources on the provider
• Enables manifest upload
• Continues until closed or escrow depleted

Stored on: Akash blockchain
Identified by: DSEQ + GSEQ + OSEQ + Provider Address

Manifest

The manifest is the detailed deployment specification sent to the provider:

• More detailed than the SDL
• Includes all service configurations
• Sent directly to the provider (not on blockchain)
• Used by provider to start containers

Stored on: Provider infrastructure
Format: YAML, similar to SDL but with more details

Complete Deployment Lifecycle

Stage 1: Preparation

What you do:

• Write SDL file describing your application
• Ensure you have sufficient ACT (USD-pegged compute credit) to fund the deployment deposit (minimum ~5 ACT / 5,000,000 uact + gas fees in AKT). You can get ACT by burning AKT or via credit card in Console.
• Choose network (mainnet or sandbox)

What happens:

• Nothing yet - you’re just preparing

Stage 2: Create Deployment

What you do:

• Submit deployment transaction to blockchain
• Include deposit (escrow) amount

What happens:

1. Deployment is recorded on blockchain with unique DSEQ
2. Order automatically opens on marketplace
3. Escrow account created with your deposit
4. Deployment status: open
5. Order status: open

Blockchain state:

Deployment #123456 (DSEQ)
  └─ Order #1 (GSEQ 1, OSEQ 1)
       Status: OPEN
       Timeout: ~5 minutes

Stage 3: Provider Bidding

What providers do:

• Monitor marketplace for new orders
• Evaluate if they can meet requirements
• Submit bids with their pricing

What you see:

• Bids appear in real-time
• Each bid shows provider, price, attributes
• Multiple bids from different providers

Typical timeline: Bids arrive within 30 seconds to 2 minutes

Blockchain state:

Deployment #123456
  └─ Order #1
       Status: OPEN
       ├─ Bid from Provider A: 9000 uact/block
       ├─ Bid from Provider B: 8500 uact/block
       └─ Bid from Provider C: 9200 uact/block

Stage 4: Accept Bid & Create Lease

What you do:

• Review bids (price, provider reputation, location)
• Accept your preferred bid

What happens:

1. Lease created on blockchain
2. Order closes (no more bids accepted)
3. Resources are permanently reserved on the provider
4. Deployment status: active
5. Lease status: active

Note: When providers submit bids, they temporarily hold the resources. If their bid is not accepted, the resources are released. Once you accept a bid and create a lease, the resources are permanently reserved until the deployment closes.

Blockchain state:

Deployment #123456
  Status: ACTIVE
  └─ Lease with Provider B
       Price: 8500 uact/block
       Status: ACTIVE

Stage 5: Send Manifest

What you do:

• Upload manifest to provider

What happens:

1. Provider receives detailed deployment spec
2. Provider pulls container images
3. Provider starts containers
4. Services become accessible

Timeline: Containers typically start within 30-60 seconds

Stage 6: Running

What happens automatically:

• Escrow pays provider per block (~6 seconds)
• Containers run on provider infrastructure
• Services are accessible via provider endpoints

What you can do:

• Access your services
• View logs
• Update deployment (limited changes)
• Monitor escrow balance

Escrow payment:

• Escrow is funded in ACT (uact). Providers are paid in ACT per block from your escrow.
• When the circuit breaker is active (new ACT mints paused), you can top up escrow with AKT to keep deployments running. Otherwise, use ACT only (recommended).

Block 1: Escrow 5.0 ACT → Pay 0.00085 ACT → Remaining 4.99915 ACT
...continues until deployment closed or escrow depleted

Stage 7: Closure

How deployments end:

Option A: You close it

• Submit close transaction
• Containers stop
• Unused escrow returned to you
• Lease status: closed

Option B: Escrow runs out

• Automatic closure when escrow hits zero
• Containers stop immediately
• Lease status: insufficient_funds

Option C: Provider closes

• Provider can close lease (rare)
• Unused escrow returned to you
• Lease status: closed

Final state:

Deployment #123456
  Status: CLOSED
  └─ Lease with Provider B
       Status: CLOSED
       Duration: 5000 blocks (~8.3 hours)
       Total cost: 4.25 ACT
       Refunded: 0.75 ACT

Deployment States

On Blockchain

Deployment States:

• open - Created, waiting for lease
• active - Lease active, running
• closed - Terminated

Order States:

• open - Accepting bids
• matched - Lease created
• closed - No longer active

Lease States:

• active - Running
• insufficient_funds - Escrow depleted
• closed - Terminated

On Provider

Manifest Status:

• pending - Manifest received, starting containers
• running - Containers active
• error - Failed to start
• complete - Stopped

Deployment Permissions

Akash allows you to grant a service read access to logs and events from all services within the same deployment group. This is useful when you have a sidecar or utility service — such as a log collector or monitoring agent — that needs to programmatically read logs from your other services or watch for deployment events.

By default, services have no special access. Permissions must be explicitly declared in the SDL.

Supported Permissions

Only read permissions are currently supported. The valid resources are:

SDL Example

The following SDL deploys a web application alongside a log-collector service that has permission to read logs and events from all services in the group — including the web service:

services:
  web:
    image: my-web-app:latest
    expose:
      - port: 80
        as: 80
        to:
          - global: true
  log-collector:
    image: my-log-collector:latest
    expose:
      - port: 8080
        to:
          - global: true
    params:
      permissions:
        read:
          - logs
          - events

profiles:
  compute:
    web:
      resources:
        cpu:
          units: 2
        memory:
          size: 1Gi
        storage:
          size: 2Gi
    log-collector:
      resources:
        cpu:
          units: 0.5
        memory:
          size: 256Mi
        storage:
          size: 512Mi
  placement:
    dcloud:
      pricing:
        web:
          denom: uact
          amount: 10000
        log-collector:
          denom: uact
          amount: 5000

deployment:
  web:
    dcloud:
      profile: web
      count: 1
  log-collector:
    dcloud:
      profile: log-collector
      count: 1

In this example, log-collector can read logs and events from both itself and the web service. The web service has no special permissions — it runs with default access only.

Escrow Accounts

How Escrow Works

When you create a deployment, you fund an escrow account with ACT only (USD-pegged compute credit):

1. Deposit: You fund escrow with ACT (minimum ~5 ACT). Get ACT by burning AKT or via credit card in Console. When the circuit breaker is active, you can also top up with AKT to keep deployments alive—otherwise use ACT only (recommended).
2. Payments: Provider is automatically paid per block from escrow in ACT.
3. Refund: When you close, unused escrow (ACT) is returned to your wallet. Unused ACT can be refunded (burned back to AKT at current price) if you no longer need it.

Escrow Calculations

Formula (amounts in ACT):

Cost per block = (bid_price) uact
Blocks per hour = 600 (at 6 seconds per block)
Blocks per day = 14,400
Blocks per month ≈ 432,000

Example:

Bid price: 10,000 uact per block (1 ACT ≈ $1)
Cost per hour: 10,000 × 600 = 6,000,000 uact = 6 ACT
Cost per day: 6 × 24 = 144 ACT
Cost per month: 144 × 30 ≈ 4,320 ACT

Escrow planning:

Deployment duration: 7 days
Cost per day: 144 ACT
Total needed: 144 × 7 = 1,008 ACT
Recommended escrow: ~1,500 ACT (buffer); fund with ACT unless circuit breaker in effect.

Monitoring Escrow

Check balance:

• Console: View deployment details
• CLI: Query deployment status

Low balance warning:

• No automatic alerts from Akash
• Implement your own monitoring
• Set reminders to check balance

Adding funds:

• You can top up escrow with ACT (recommended). When the circuit breaker is in effect, you can also add AKT to keep deployments running.
• Use CLI: provider-services tx deployment deposit (or equivalent for ACT)
• Use Console: View deployment → Add funds
• Plan initial escrow generously; use ACT only unless the circuit breaker requires AKT top-up.

Deployment Updates

What CAN Be Updated

Container image tag:

# Before
image: myapp:v1.0

# After update
image: myapp:v1.1

Environment variables:

# Before
env:
  - NODE_ENV=development

# After update
env:
  - NODE_ENV=production

Command and arguments:

# Before
command: ["npm"]
args: ["start"]

# After update
command: ["npm"]
args: ["run", "prod"]

What CANNOT Be Updated

Resource requirements (CPU, memory, storage, GPU)

Service count (replicas)

Port configurations

Storage attributes

Provider/Lease (tied to specific provider)

To change these: Close deployment and create new one

Update Process

Console:

1. Click “Update Deployment”
2. Modify SDL
3. Save and deploy

CLI:

# Update deployment
provider-services tx deployment update deploy-updated.yml \
  --dseq <deployment-id> \
  --from <wallet> \
  --chain-id akashnet-2 \
  --gas auto \
  --gas-adjustment 1.5

What happens:

1. New SDL hash recorded on blockchain
2. Updated manifest sent to provider
3. Provider re-pulls images if changed
4. Containers restart with new configuration
5. Brief downtime during restart (~10-30 seconds)

Multi-Group Deployments

Advanced: You can deploy multiple service groups with one deployment:

deployment:
  frontend:
    akash:
      profile: frontend
      count: 1
  backend:
    akash:
      profile: backend
      count: 1

Each group:

• Gets its own order (OSEQ)
• Can have different providers
• Independent lease lifecycle
• Separate pricing

DSEQ structure:

Deployment #123456
  ├─ Order 1 (frontend)
  │    ├─ Bid from Provider A
  │    └─ Lease with Provider A
  └─ Order 2 (backend)
       ├─ Bid from Provider B
       └─ Lease with Provider B

Common Patterns

Long-Running Services

For services that should run indefinitely:

# High escrow deposit
# Monitor balance regularly
# Set up external monitoring
# Have update/restart strategy

Escrow recommendation: 30-90 days worth

Temporary/Test Deployments

For short-term testing:

# Minimal escrow (just enough for test duration)
# Use sandbox network
# Close promptly after testing

Escrow recommendation: Hours to days worth

Batch Jobs

For one-time compute jobs:

# Calculate job duration
# Fund escrow accordingly
# Close immediately after completion

Tip: Monitor logs to detect completion, then close

Troubleshooting

No Bids Received

Possible causes:

1. Price too low - Increase maximum price in SDL
2. Resources unavailable - Reduce requirements or change specs
3. Invalid SDL - Check SDL syntax
4. Network issues - Try different network (mainnet vs sandbox)
5. Restricted to audited providers - Remove or adjust signedBy field if you’re limiting deployment to only audited providers

Solution: Close order, adjust SDL, redeploy

Deployment Won’t Start

Possible causes:

1. Invalid manifest - Provider can’t parse your config
2. Image pull failure - Wrong image name or private without credentials
3. Resource allocation failure - Provider overcommitted

Solution: Check provider logs, verify SDL, contact provider

Escrow Depleted Unexpectedly

Cause: Underestimated costs or higher bid price than expected

Prevention:

• Add 50-100% buffer to escrow estimates
• Monitor balance regularly
• Set up external alerts

Recovery: Close and redeploy with more escrow

Can’t Access Services

Possible causes:

1. Containers not started - Check provider status
2. Wrong endpoint - Verify service URL
3. Port configuration - Check expose settings in SDL
4. Provider networking - Contact provider

Solution: Check logs, verify configuration, test connectivity

Best Practices

Planning

Calculate escrow needs accurately

• Estimate duration
• Add 50-100% buffer
• Account for potential overruns

Test on sandbox first

• Validate SDL
• Test deployment process
• Estimate costs

Document your deployments

• Save SDL files
• Record DSEQ numbers
• Note provider addresses

Monitoring

Check regularly:

• Escrow balance
• Service health
• Provider uptime
• Resource usage

Set up external monitoring:

• Uptime monitoring (UptimeRobot, Pingdom)
• Log aggregation (if needed)
• Cost tracking

Maintenance

Update images regularly

• Security patches
• Bug fixes
• Feature updates

Plan for migrations

• Have backup provider list
• Document migration process
• Test recovery procedures

Advanced Topics

Deployment Automation

Automate deployments with CLI/SDK:

• CI/CD integration
• Scheduled deployments
• Auto-scaling (via redeploy)
• Monitoring-driven updates

Cost Optimization

Strategies to reduce costs:

• Accept lowest bid automatically
• Right-size resources
• Use sandbox for development
• Close deployments when not needed
• Batch similar workloads

High Availability

For production services:

• Deploy to multiple providers
• Use external load balancer
• Implement health checks
• Have failover procedures
• Monitor continuously

Related Topics

• Providers & Leases - Choosing and working with providers
• SDL Reference - Complete SDL documentation

Need help? Ask in Discord #deployments channel!