Skip to content
Trigora

Search docs by title or keyword.
    Product Docs Pricing Research Blog GitHub Start building →
    Start building →

    Production considerations

    Review these considerations before deploying a production workload to Trigora Cloud.

    Effects and external systems

    Section titled “Effects and external systems”

    After an effect outcome is committed, recovery reuses that outcome. If the process fails after the effect starts but before its outcome commits, the effect may run again. For external APIs that are not inherently idempotent, provide an idempotency key to fn and store it in a system that survives retries. Trigora does not provide exactly-once delivery to external systems.

    Artifact pinning

    Section titled “Artifact pinning”

    Waiting Executions stay on the artifact they started with. Deploying a new version does not migrate them. Cancel and start again if you need the new code. See Artifact pinning.

    Cancellation and retries

    Section titled “Cancellation and retries”

    trigora cancel stops that Execution. It does not undo a committed effect. Compensate in your own system if you need to.

    Trigora does not expose a separate retry-policy object. Re-execution of an uncommitted effect follows the failure behavior described above rather than a configured retry count.

    Secrets

    Section titled “Secrets”

    Store TRIGORA_TOKEN in the environment or a .env file, never in source control. Event payloads and Program constants may be stored with the Execution, so do not use them for credentials or other sensitive values.

    Trigora Cloud stores project secrets encrypted at rest. Effect code reads the current values from the runtime environment when the effect runs. A replace or delete applies on the next effect attempt. An attempt that has already started keeps the environment it started with. Secret values are not pinned to a Program version.

    A Program deployed before secrets support must be redeployed once before its effects can see managed secrets. After that deploy, changing a value does not require another deploy.

    trigora dev does not use Cloud secrets. It uses the environment of the local process, including a project .env file. See Secrets.

    Payloads

    Section titled “Payloads”

    Inputs, event payloads, and results are stored as JSON on the Execution record and count toward durable storage. Trigora does not publish a separate byte limit for these payloads. Keep them small, and use external object storage rather than event payloads for large files.

    Language

    Section titled “Language”

    Constructs outside the supported language profiles fail at compile time. See Unsupported constructs. Promise.all, Promise.race, gather, race, and Rust join / race compile only in the forms documented under Structured concurrency. Unsupported forms cannot be deployed and never run under an alternate recovery model.

    Billing

    Section titled “Billing”

    Cloud meters durable operations, measured execution CPU, and durable storage. Waiting is free. Free includes $5 of monthly usage and has no overages. When that credit is exhausted, new top-level starts are refused. Executions that already exist continue, including timers, events, child executions, and recovery. Pro is a $60/month minimum and includes $60 of usage. Details: Usage & billing.

    Recovery

    Section titled “Recovery”

    Recovery restores a continuation instead of replaying the completed prefix. This does not eliminate failures in external systems called by effects. The measurements in the technical report describe the tested workloads and should not be interpreted as a general latency guarantee. See How recovery works.