Deploy CTFreak Task Scheduler

Schedule remote commands and workflows with durable execution history.

Deploy CTFreak Task Scheduler

Deploy and Host CTFreak Task Scheduler on Railway

Schedule remote commands and workflows with durable execution history.

Draft status: Configuration and upstream documentation reviewed. Container startup, Railway application workflows, restart behavior, backup restoration and costs remain unverified.

About Hosting

Schedule remote commands and workflows with durable execution history.

ServiceRolePersistent path
appPrivate application or dependency/data
ctfreakPublic owner gatewayNone

Why Deploy

Run this application in your own Railway project, with explicit configuration and storage under your control.

Common Use Cases

  • Schedule remote commands and workflows with durable execution history.

Dependencies for CTFreak Task Scheduler

Deployment Dependencies

The application images are pinned by registry digest. Database services, when included, stay on the private network. One replica is supported for each volume-backed service.

First use

Open the ctfreak service's HTTPS domain. Sign in to the owner gateway with username admin and its generated ACCESS_PASSWORD. Complete the application's own setup afterward.

API calls must also send X-Template-Key with that owner password. The gateway forwards native Bearer tokens, strips Basic Authorization, and limits requests to 32 MiB. Browser sessions receive a secure owner cookie. Native clients, webhooks and public sharing require specific compatibility checks before use. Gateway /healthz only checks the proxy, not application readiness.

Use the generated owner gateway credential, then sign into CTFreak initially as admin / ctfreak and immediately change that application password. Add your own SSH or WinRM credentials and reachable remote nodes.

Scope and limitations

  • The known upstream first-run password is protected by the owner gateway; change it during first setup.
  • Paid features require your own upstream license. Docker does not include Ansible integration or support the Sovereign edition.
  • Local commands execute in the Railway container, not on a Railway host. Remote nodes must be reachable from Railway.

Acceptance checks before use

  • Change the initial application password and create a harmless echo task.
  • Run the task, restart, and verify its definition and execution history remain.
  • Confirm generated credentials are distinct on a second fresh deployment.
  • Back up every listed persistent path and database, then restore into a separate test project.
  • Measure Railway usage with representative data and workload before estimating operating costs.

Backups and upgrades

Back up databases, file volumes, encryption keys and configuration together. Keep a copy outside the running project. Review upstream migration notes before changing a digest; rollback can require restoring a compatible database and files, not just selecting an older image.

Sources and selection evidence

Product and alias searches found no matching public Railway listing during this research. This is a bounded search result; private, unindexed or differently named listings may exist. It is not evidence of demand or revenue.

Upstream software retains its own license and edition restrictions. This deployment draft does not imply upstream endorsement.


Template Content

More templates in this category

View Template
Rocky Linux
Hosted Rocky Linux 9 workspace with SSH and persistent storage. 🚀

codestorm
47
View Template
Foundry Virtual Tabletop
A Self-Hosted & Modern Roleplaying Platform

Lucas
71
View Template
Letta Code Remote
Run a Letta Code agent 24/7. No inbound ports, just deploy.

Letta
51