How to Launch Callaba Cloud on AWS and Start Your First Live Stream

The fastest way to start with Callaba is the cloud path. Instead of assembling a streaming stack first and figuring out infrastructure later, you can launch Callaba Cloud on AWS, sign in to the dashboard, create your first SRT server, and send a real stream from OBS in one guided workflow.

This page is built for that exact outcome. It is not a generic documentation dump. It is the practical path from zero deployment to first working stream.

Why this matters: cloud is the main way most teams should evaluate Callaba. It lets you prove the workflow quickly, test real contribution paths, and decide later whether you need deeper self-hosted control. New cloud users also get the first 5 days free, which makes the cloud route the best place to validate the product with real traffic rather than guesses.

What you will accomplish on this page

• Launch Callaba Cloud on AWS.
• Sign in to the dashboard safely.
• Create your first SRT server.
• Send a stream from OBS Studio.
• Receive and verify playback.

Part 1. Launch Callaba Cloud on AWS

The AWS route is the fastest production-shaped way to start. You launch a real cloud instance, open the dashboard, and immediately get a controllable environment for ingest, routing, failover, and playback workflows.

Before you begin, make sure you have an AWS account. If you do not, create one first. Once you are ready, open the Callaba Cloud listing on AWS Marketplace and start the launch flow.

Launch Callaba Cloud on AWS Marketplace

1. Open the AWS Marketplace page and click Continue to Subscribe.

2. Accept the software terms and continue.

3. Wait until the configuration step becomes available, then continue.

4. Choose the AWS region closest to your publishers and viewers. This is one of the simplest ways to reduce avoidable latency and improve operational comfort from the start.

5. Choose the instance type. If you are unsure, c5.xlarge is a practical starting point for many early evaluations.

6. Leave VPC and subnet settings unchanged unless your team already knows why it needs something different.

7. Create the security group from the seller settings. Then review ports carefully. The default posture is broad so different workflows can start quickly, but once you know which ports you actually need, tighten the rules. That is the right production habit.

8. Create or select the SSH key pair. Save the .pem file somewhere safe in case you need direct instance access later.

9. Verify the security group and key pair, then click Launch.

10. Your Callaba Cloud instance is now being deployed.

Part 2. Sign in to the dashboard and secure the instance

Once the instance is live, the next goal is simple: open the dashboard and make sure you understand the basic AWS operating rule. AWS charges while the instance is running, so do not leave it up indefinitely after testing.

11. Open your AWS Console, go to EC2, and find the running instance.

12. Make sure you are in the correct region, then open Instances and wait until the instance state is Running and the status checks are complete.

13. Copy the Public IPv4 address and open it in your browser with http://, not https://, on first access.

14. Sign in to the Callaba Cloud dashboard using:

• Login: admin
• Password: your EC2 instance ID

15. Once inside, pause for one operational rule: when your work is over, stop or terminate the EC2 instance so AWS does not keep charging for idle runtime. This matters in every cloud trial and every real project.

Part 3. Create your first SRT server

Now we move from deployment into actual streaming. For a first practical workflow, SRT is a good place to start because it gives you a resilient contribution path and exposes the core logic of the platform clearly.

16. Go to the SRT Servers section and click Add new.

17. Create the server and fill in the key settings:

• Name: anything recognizable.
• Port: publisher port for sending the stream in.
• Receiver Port: receiver port for taking the stream out.
• Latency: use your own value or let the platform suggest one.
• Max network bandwidth: use the built-in check if you are unsure.
• Timeout of idle stream: controls reconnect behavior.
• Passphrase: optional, if you want controlled access.
• Routing settings: useful for pull, push, and redundancy workflows.

If you want more depth on this object itself, the dedicated page is SRT server.

Part 4. Send your first stream from OBS Studio

18. In the SRT server list, open Info and copy the SRT Publisher URL.

Callaba supports both host/port and stream-ID style connection models. That flexibility matters because different encoders and devices prefer different connection patterns.

19. Open OBS Studio, add your sources, go to Settings → Stream, paste the SRT Publisher URL into the server field, and start streaming. If you want the longer setup context around OBS paths, the adjacent guide is how to start SRT streaming in OBS Studio.

At this point you should see the stream bitrate and activity in the dashboard. That is your first proof that the cloud workflow is live end to end.

Part 5. Verify playback

20. For a fast receiver-side check, go back to the SRT server, open Info, and copy the SRT Receiver URL.

21. Open VLC, choose File → Open Network, paste the receiver URL, and confirm playback.

What to do next in Callaba Cloud

Once this first stream works, the cloud deployment becomes much more valuable than a demo because you can continue directly into real workflows:

• Multi-streaming if one input needs to reach many destinations.
• Main/backup SRT failover if contribution continuity matters.
• Video API if the workflow needs software integration.
• Video on demand if replay and playback are part of the same product.

If you want to evaluate cloud-first without operating servers locally, this is the best starting path. If later you need tighter infrastructure ownership, the next step is the self-hosted streaming solution, but for most teams the cloud launch is the fastest and safest way to prove value first.

Final practical rule

Start with the cloud path when the goal is to get to a working streaming system quickly. Launch the instance, sign in, create the first SRT server, send one real stream, and only then decide whether you need deeper self-hosted control. That sequence reduces friction, speeds up evaluation, and keeps the buying path aligned with the actual workflow.