Advanced Features

ACT provides several advanced features beyond basic deployments that give you fine-grained control over your infrastructure.

Tag-Based Placement

ACT supports Server Labels (tags) that allow you to control where your resources are deployed based on server characteristics and requirements.

Setting Server Labels

Labels are key-value pairs that you can assign to servers. Common use cases include:

• region=us-east-1, region=eu-west-1 - Geographic placement
• environment=production, environment=staging - Environment segregation
• gpu=true - Specialized hardware requirements
• database=true, worker=true - Role-based placement

Placement Constraints

When creating or updating a resource, you can specify placement constraints using these labels:

# Resource configuration example
placement_constraints:
  - key: region
    operator: ==  # or !=, in, notin
    values:
      - us-east-1
  - key: gpu
    operator: ==
    values:
      - "true"

How It Works

ACT’s scheduler evaluates placement constraints during deployment:

1. Filters servers that match all required constraints
2. Scores candidates based on resource availability
3. Selects the optimal server for deployment

Use Case Example: Deploy a GPU-accelerated ML service only to servers labeled gpu=true in the us-east-1 region.

Direct Source Upload

While ACT is optimized for Git-based deployments, it also supports Direct Source Upload for scenarios where you need to deploy code without using Git.

Upload Methods

ZIP Archive Upload

Upload a ZIP file containing your application source code via the API:

# Upload and deploy a ZIP archive
curl -X POST https://api.actplatform.dev/api/v1/resources/:id/deploy \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -F "[email protected]"

The archive should contain:

• Your application source code
• (Optional) A Dockerfile at the root
• (Optional) package.json, requirements.txt, or other build configuration files

Build Process

ACT processes uploaded sources as follows:

1. Extracts the archive to a temporary build directory
2. Detects project type (Node.js, Python, Go, Rust, etc.)
3. Uses Nixpacks or your Dockerfile to build the image
4. Deploys the resulting image to your servers

Use Case Example: Deploying a built application artifact or a private codebase that cannot be accessed via Git.

Cron Services

ACT includes a dedicated scheduler for Cron Services - resources that run on a schedule rather than continuously.

Crontab Syntax

Cron services use standard crontab syntax with five fields:

┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of month (1 - 31)
│ │ │ ┌───────────── month (1 - 12)
│ │ │ │ ┌───────────── day of week (0 - 7) (both 0 and 7 are Sunday)
│ │ │ │ │
* * * * * command

Examples

# Run every 5 minutes
schedule: "*/5 * * * *"

# Run at 2:30 AM every day
schedule: "30 2 * * *"

# Run at midnight on the first of every month
schedule: "0 0 1 * *"

# Run every Monday at 9 AM
schedule: "0 9 * * 1"

Creating a Cron Service

resource_type: cron
schedule: "0 2 * * *"
image: mycompany/data-processor:latest
environment:
  - API_KEY=secret_key

Coalescing Behavior

ACT implements coalescing to prevent duplicate executions when multiple intervals are missed:

• If the scheduler falls behind (e.g., server was down), it will run the job only once for the most recent missed interval
• This prevents “backlog explosion” where jobs pile up and execute all at once
• The job always runs with the most recent schedule time

Example: If a job scheduled to run every minute misses 5 minutes during downtime, it will execute once (not 5 times) when the scheduler resumes.

Limitations

• Minimum interval: 1 minute
• Maximum concurrent jobs: Limited by server resources
• Timezone: Uses server timezone (configurable per environment)