Operations
Operate JetEncode as a versioned workload: observe health, keep evidence, rehearse recovery, and change production through a tested release path.
Health and services
Use the application’s verified readiness signal in addition to provider compute checks. Record service state and resource saturation before restarting a failed job.
After setup, open the UI on port 80 and confirm GET /v1/sysinfo responds before submitting production jobs.
Logs and monitoring
Document each log source, retention behavior, identifiers, sensitive-data considerations, and the collection path into your provider or third-party monitoring system. Never assume export is automatic.
Use the browser UI and HTTP API to inspect job state and errors. JetEncode does not automatically export logs to an external service.
JetEncode sends no automatic analytics, telemetry, diagnostics, or customer media to JetEncode.
Error recovery
- Preserve job ID, timestamp, exact error, version, and Region.
- Check health, capacity, permissions, storage, and input readability.
- Retry only when documented as safe.
- Escalate with redacted logs and a minimal reproduction.
Upgrades and rollback
Pin production to an image version. Test a new release separately, compare outputs, then promote through your normal change process.
Publish each JetEncode release as a new versioned cloud image. Validate it separately and retain the prior image version for rollback.
Backup and recovery
JetEncode does not currently provide a supported restore procedure for its bundled PostgreSQL configuration and job history. Keep source media and required outputs in durable object storage. Recover by launching a known AMI version, reapplying configuration, reconnecting storage, and submitting new jobs as needed.
The AMI default root volume is suitable for evaluation. Increase it for the largest expected source, outputs, and concurrent `/tmp` working sets; keep durable media in object storage.
Get help
Follow the support request template and never send credentials or private media.