Runtime

Project Context

Every bot we delivered to a client ended at the same question: where will it live? Generic hosts expose dozens of options the client doesn't need and leave the bot's code within reach of anyone with panel access. Runtime was built to close that gap: a DayronLabs service designed solely to run custom bots, where the client sees what they need and nothing else.

Technical Challenge

The challenge was giving the client real control over their bot — start it, stop it, read its logs, manage its data and backups — without ever handing over the code or the internal process, and with guarantees that one client cannot affect another on the same infrastructure.

Problems Solved

• •Immutable code: the product lives inside the image on a read-only path. The client's only persistent data sits on their own volume, and no file on that volume is ever executed as code.
• •Verified isolation: A/B tests between clients and a fixed resource contract (CPU, RAM, disk, swap, and process limit) that stops one bot from consuming another's resources.
• •A noise-free panel: a custom visual layer on top of Pterodactyl that hides generic hosting tools and leaves only status, controls, files, a read-only console, and backups.

Technical Execution

Its own public landing page, a Pterodactyl Panel with a versioned overlay, Wings nodes, an immutable Node.js 22 image for the runtime, manual backups to Cloudflare R2, reproducible staging automation, observability, and end-to-end checklists before onboarding each client.

Results Obtained

Runtime is in its pilot phase: the panel, Wings, client isolation, R2 backups, and real resource limits have all passed their validation gates. Client onboarding is approved individually while we open the first spots.

Visual Evidence