Installation or instant launch

Before you authenticate or make API calls, decide where Callaba Engine will run. This is primarily a deployment choice: use AWS when time to first instance matters most, or use a self-hosted deployment when network placement, infrastructure policy, and repeatability matter more.

Choose the path that fits the work

PathBest forWhat to watch for
AWS launch Fast evaluation, API validation, workflow prototyping, and short setup cycles. Quicker to start, but less suitable if you need private network placement, custom host preparation, or strict infrastructure controls from day one.
Self-hosted / on-premises Production-aligned environments, internal network deployment, version pinning, and controlled topology. More preparation up front, but better when firewalling, storage, monitoring, and host standards are part of the deployment plan.

AWS launch

Choose AWS launch when the main goal is to get a working instance online quickly and start exercising the API. This is usually the right starting point for evaluations, proof-of-flow testing, or early client integration when you do not yet need a production-shaped environment.

In practice, AWS launch is the shorter path if your team wants to confirm authentication, create streams, test contribution flows, or validate automation before spending time on Linux host preparation and site-specific networking.

Self-hosted / on-premises

Choose self-hosted deployment when the runtime environment is part of the requirement. This is typically the better path if you need the engine inside your own network boundary, need predictable ingress and egress rules, or must align the install with existing operations, security, or hardware standards.

For self-hosted installations, use the guide that matches the version you intend to operate. Use 8.2 for most new self-hosted environments unless you have a specific reason to stay aligned with an existing 7.3 deployment or a pinned validation target.

  • Version 8.2: appropriate for most new self-hosted builds.
  • Version 7.3: appropriate when compatibility with an existing deployment or test matrix requires it.

Once the instance is up and reachable, continue with Authorization to obtain the JWT token and send it in the x-access-token header.