A lightweight agent runtime for cloud, edge, and embedded Linux environments.

SchedNext treats automation as deployable agents that can be scheduled, executed, and observed through filesystem-native interfaces.

It is designed for environments where traditional scheduling platforms may be too heavy or unavailable, including edge devices, cloud VMs, custom Linux distributions, containers, and air-gapped systems.

SchedNext combines:

• Agent execution
• Persistent runtime state
• Filesystem-based observability
• Runtime control via CLI

without requiring databases, web services, or large infrastructure dependencies.

• ⏱ Cron-based scheduling
• 🔁 Persistent agent state
• 🔒 Runtime locking
• 🧾 Atomic config updates
• 🖥 CLI runtime control
• 📊 Filesystem observability
• 🧠 Dynamic runtime state projection
• 📦 Small static binaries
• ⚡ Low memory footprint

SchedNext can be installed using the official install script.

Requirements

• Linux (amd64 or arm64)
• Root access
• FUSE support (for StateLens)

Option 1 - Download First

curl -O https://raw.githubusercontent.com/Ezeji/schednext/main/install.sh 

chmod +x install.sh 

sudo ./install.sh

Option 2 - Install Latest Release

curl -fsSL https://raw.githubusercontent.com/Ezeji/schednext/main/install.sh | sudo bash

Option 3 - Install Specific Version

curl -fsSL https://raw.githubusercontent.com/Ezeji/schednext/main/install.sh | sudo bash -s -- v0.1.0

The installer accepts an optional version argument.

Examples:

sudo ./install.sh sudo ./install.sh v0.1.0

/opt/schednext-runtime
├── bin
│   ├── schednext
│   └── schednext-agent
├── heartbeat.sh
├── schednext.config
└── user-agents...

SchedNext exposes live runtime state through a virtual filesystem.

Inspired by Linux /proc and /sys, runtime state can be inspected using standard Unix tools.

Examples:

cat /statelens/cpu/summary

cat /statelens/mem/summary

cat /statelens/schednext/all

cat /statelens/schednext/sensor

/statelens
├── cpu
│   └── summary
├── mem
│   └── summary
├── net
│   ├── interfaces
│   └── routes
└── schednext
    ├── all
    ├── heartbeat
    └── sensor

$ cat /statelens/cpu/summary
 18:42:31 up 3 days,  2 users,  load average: 0.15, 0.09, 0.05

$ cat /statelens/mem/summary
              total        used        free      shared  buff/cache   available
Mem:           3.8G        512M        2.4G         12M        896M        3.1G

$ cat /statelens/schednext/all
 heartbeat | idle | enabled=true | exit=0
 sensor | running | enabled=true | exit=0

SchedNext prioritizes:

• Simplicity over complexity
• Predictable behavior over magic
• Filesystem primitives over infrastructure dependencies
• Low resource usage over feature bloat

SchedNext intentionally does not write logs to disk.

• Disk logging increases I/O
• Log files grow unbounded
• Log buffering consumes RAM
• Minimal OS / edge devices suffer from log overhead

• Logs go to stdout/stderr
• Users may redirect or pipe logs externally
• Future versions may support pluggable log sinks

Agent execution results are persisted via:

• lastRunAt
• lastExitCode

inside the configuration file.

SchedNext consists of three runtime components:

The CLI communicates with the agent via IPC (Unix socket).

SchedNext uses a JSON configuration file:

schednext.config

Example:

{
  "version": 1,
  "jobs": [
    {
      "id": "sensor",
      "binary": "sensor-agent",
      "cron": "*/2 * * * *",
      "enabled": false,
      "lastRunAt": "2025-12-20T12:45:00Z",
      "lastExitCode": 2025,
      "lockUntil": "2025-12-20T12:45:00Z",
      "maxRuntimeSeconds": 2
    }
  ]
}

SchedNext supports standard 5-field cron expressions:

MINUTE HOUR DOM MONTH DOW

Examples:

*/2 * * * *    → Every 2 minutes
0 * * * *      → Every hour
0 0 * * *      → Daily at midnight

Example:

./schednext-agent

Where /opt contains schednext runtime directory:

/opt/schednext-runtime/schednext.config

The agent:

• Locates runtime directory
• Evaluates cron schedules
• Applies runtime locks
• Executes binaries
• Streams runtime state
• Persists agent state

Basic commands:

schednext start <agent-id>
schednext stop <agent-id>

Examples:

schednext start sensor
schednext stop sensor

Build binaries from source:

go build -o schednext-agent ./cmd/agent
go build -o schednext ./cmd/cli

Cross-compile examples:

GOOS=linux GOARCH=amd64 go build -o schednext ./cmd/cli
GOOS=linux GOARCH=amd64 go build -o schednext-agent ./cmd/agent
GOOS=linux GOARCH=arm64 go build -o schednext ./cmd/cli
GOOS=linux GOARCH=arm64 go build -o schednext-agent ./cmd/agent

SchedNext is designed for environments where lightweight deployment, runtime observability, and minimal operational dependencies are important.

Examples:

• Cloud VM automation
• Edge devices
• Robotics runtimes
• IoT gateways
• Industrial automation nodes
• Custom Linux distributions
• Air-gapped systems
• Containers without cron or systemd

Planned improvements:

• Event-driven job triggers
• Webhook-based execution
• Remote node monitoring
• Multi-node fleet management
• Lightweight web dashboard
• SchedNext OS
• ARM-first edge deployment tooling

Contributions are welcome.

Guidelines:

• Keep changes minimal & focused
• Preserve low-resource design goals
• Avoid heavy dependencies

Early-stage / evolving design.

Config structure and APIs may change.

MIT License