Source Type
Each service is deployed from one of two sources:
For GitHub sources, you can specify the branch, root directory, and whether to auto-deploy on push. See GitHub Integration for details.
Environment Variables & Secrets
Secrets are encrypted at rest and injected into containers at runtime. They are never baked into images. Each secret has a key and an encrypted value, scoped to a single service. You can add, update, and remove secrets from the service settings in the web UI. Secrets are passed as environment variables to the container when it starts.Service crons
Service crons send scheduled HTTPGET requests to your application. Define them under service.crons in techulus.yml:
/, and omit a query string or fragment. Schedules use five-field cron expressions in UTC. You can configure up to 100 crons per service.
Add these service secrets from the web UI:
The destination must be reachable from the control plane. Cron requests do not follow redirects or retry, and each request has a 10-second deadline. If the control plane misses multiple intervals, it sends only the latest due occurrence instead of backfilling every missed run.
Missing or invalid configuration produces a skipped run. Redirects and non-2xx responses produce failed runs. The Crons section in service configuration shows the latest result. Full history is available in service logs and follows the configured log retention period.
tc apply treats service.crons as the complete desired list. Removing the field or setting it to an empty list removes all cron definitions. Cron-only changes take effect without creating a deployment revision.
Start Command
Override the container’s default entrypoint by setting a custom start command. This is useful when deploying from pre-built images that need different startup behavior.Resource Limits
You can set CPU and memory limits per service:
New services default to the Large preset: 2 CPU cores and 1024 MB memory. You can change the preset or choose No limit to let the container use whatever resources are available on the host.
Resource limits are runtime caps, not reserved capacity. Placement uses current server health and replica distribution, but it does not require the sum of configured limits to fit as guaranteed minimum allocation.
Health Checks
Health checks verify that a container is ready to receive traffic. When configured, the platform waits for the health check to pass before routing traffic to a new deployment.
Health check statuses:
If no health check command is set, deployment readiness only confirms that the container started. The platform still waits for DNS, proxy routes, certificates, and a successful Traefik configuration reload before marking the rollout complete, but it does not verify that the application inside the container accepts requests. Configure a health check when application readiness matters.