OBS can run on an Oracle Cloud Infrastructure (OCI) Ubuntu virtual machine and send a live stream to YouTube, but installing OBS is only one part of the work. You also need a usable Linux display session, network access to YouTube’s ingest service, and an instance that can sustain your chosen encode.
This guide sets out a reproducible way to plan and test that arrangement, not a promise that a particular OCI shape will encode a particular format or stay live without interruption. Choose an Ubuntu image, shape and region deliberately, test the actual display and stream path, and document what happens when the process or connection fails.
Choose the Ubuntu image, architecture, shape and region
Start by recording the choices you intend to test. For a practical baseline, use an OCI Ubuntu 24.04 LTS platform image on x86_64, in the region nearest the expected audience or your operating team. This is a stated starting configuration, not a claim that it is the only working combination or that it has been validated end to end. If you select a different Ubuntu release or architecture, check that OBS’s current installation guidance and the software packages you need cover it.
The OBS Project’s current download page described its Ubuntu PPA for Ubuntu 24.04 and newer at the time of the research behind this guide. That makes 24.04 a straightforward release to investigate, but package availability and support can change. Check the OBS Project download and installation instructions for your selected release before creating the VM. An older OBS Linux installation article gives broader Ubuntu guidance, but should not be treated as evidence of current support for every release.
Choose a shape based on the scene and encoder you plan to run, not on the assumption that a low-cost or free-tier VM is sufficient. OBS’s CPU requirements vary with the encoder, resolution, frame rate and scene complexity. A static image with audio has a different workload from a scene with animated visualisers, browser sources, transitions or several video layers. The basic OBS requirements are a floor, not a capacity guarantee.
The region also affects the route between your VM and YouTube’s ingest service, and can matter for the audience’s experience. It does not, by itself, establish that the VM has enough outbound capacity or that its connection will remain stable. Ensure the selected subnet has a route to the internet for outbound streaming, and verify performance from that actual instance and region under the load you expect.
Keep a short deployment record before proceeding: Ubuntu release and image, CPU architecture, OCI shape, region, subnet, OBS version, encoder, resolution and frame rate. If you later change one of these, repeat the relevant tests. This is especially useful when a channel runs the same content overnight and a silent change to the image or scene could alter behaviour.
Prepare the OCI VM and administration access
Create a Compute instance from an Ubuntu platform image and place its virtual network interface in the subnet you intend to use. Decide whether you will administer it through a public IP with tightly restricted SSH access, or through a private access method such as an OCI Bastion. Oracle’s Compute instance launch guidance describes image, subnet and public-IP choices; follow the current console workflow because labels and options may change.
For SSH, allow access only from an address range you control where possible. Avoid a rule that exposes administration to the whole internet simply because it is quicker to set up. Use SSH keys and keep a separate, tested way to regain access if your usual network address changes. Before installing OBS, connect, apply the Ubuntu updates you need, and confirm you can reconnect after a reboot.
Decide how you will use the machine before choosing its shape. OBS is a graphical application, even if you intend to leave it running unattended. An Ubuntu server image may not have a desktop session. A VM that accepts SSH connections is not automatically ready to launch OBS or render its scenes.
Plan the display arrangement at this stage. You might attach OBS to a desktop session you administer remotely, or establish a virtual display/session appropriate to your environment. The official OBS requirements specify an X Window System or Wayland and OpenGL 3.3 for Linux. They do not prescribe an OCI-specific virtual-display configuration. Do not assume that a shell-only login supplies these components, or that a remote desktop will remain available after logout or reboot without deliberate configuration.
Before treating the VM as an always-on candidate, test the actual session lifecycle you plan to use. Launch OBS, close and reopen the remote administration connection, and verify whether the application remains running and its display remains usable. Then test a reboot and the intended automatic-start method. A successful interactive launch is not evidence that the same process will resume correctly after a restart.
Install OBS and establish a Linux display
Once the release is chosen, use the OBS Project’s current instructions for that exact Ubuntu version. The PPA commands shown on the OBS download page during research were:
sudo add-apt-repository ppa:obsproject/obs-studio
sudo apt update
sudo apt install obs-studio
These commands are an example for the documented package route, not a substitute for checking the current page or confirming that the PPA covers your image. Run them in a maintenance window, note the OBS version installed, and check for errors rather than assuming a completed package command means the application is ready to stream.
OBS lists OpenGL 3.3 and X Window System or Wayland as Linux requirements. On a VPS, the hard part may be arranging for a supported graphics/display context, not the package installation itself. Choose one arrangement, write down how it starts, and verify that OBS actually opens in it. The reviewed official requirements do not recommend a particular OCI display setup, so the right choice depends on how you will administer and recover your own VM.
After the first launch, inspect OBS’s settings and scene on the same display arrangement you will use unattended. Add only the sources needed for the channel. A devotional playlist might use a video source, title and audio; a lofi station might add a visualiser or moving background. Browser-based sources and animated scenes can raise the workload, so a configuration that works with a still image should not be assumed to behave identically after you add motion.
If OBS reports a graphics or rendering problem, resolve that before adding the stream key. Check that the session is still present and that the graphics path meets the application’s stated requirements. A display arrangement that depends on a logged-in operator may be unsuitable for a process expected to continue after that session ends. Conversely, a virtual session still needs explicit testing across logout, restart and disconnection; its existence alone does not demonstrate recovery.
For a file-led channel, decide whether OBS is the right control point for your operating needs. The article on replaying the same video file all day on YouTube Live covers the content-loop question, while this guide is about running OBS on a VM. If the main requirement is to keep a recorded programme live with your computer off, compare that workflow with cloud playout for a 24/7 lecture stream before settling on a graphical desktop you will need to maintain.
Configure OCI networking for administration and outbound streaming
Treat OCI network rules and the Ubuntu guest’s own firewall as separate controls. OCI recommends network security groups (NSGs) over security lists for managing rules for instance resources. Use the current OCI VCN security rules documentation to understand the distinction and configure rules for your instance and subnet.
For direct SSH administration, create an inbound rule limited to your trusted source range and the SSH service you use. If you use a bastion or another private access path, follow that method’s requirements instead of adding an unnecessary public SSH opening. Keep a record of which rule provides access so you can review it later.
OBS sends the stream out to YouTube. For this outbound-push workflow, preserve the outbound route and connectivity the VM needs to reach YouTube’s ingest service. You do not need to open an inbound YouTube port merely to send a stream; add inbound rules only when a separate service you operate justifies them. Do not confuse the ability to reach the VM for administration with the VM’s ability to make an outbound connection.
Oracle documents the guest firewall as another layer, but its Ubuntu platform-image guidance warns that UFW changes might prevent the instance from booting. Before changing host firewall rules, review Oracle’s current Ubuntu platform image guidance and use its Ubuntu-specific instructions. Keep a recovery path before making a change that could block SSH or disrupt boot.
Once the network is configured, verify it from the guest rather than only inspecting the OCI console. Confirm that you can reconnect over your chosen administration route and that the VM has outbound internet connectivity. Then send a private or unlisted test from OBS and check whether YouTube receives it. If that fails, separate the diagnosis into display/OBS launch, guest network, OCI rules or routing, and YouTube ingest rather than changing several layers at once.
The configured video bitrate is not the entire network requirement: audio, protocol overhead and variation need room as well. Treat sustained outbound capacity as something to test from the selected instance, not as a promise implied by an OCI shape label. If the stream disconnects after running for a while, the OBS YouTube disconnect troubleshooting guide can help you distinguish network symptoms from encoder or session problems.
Set YouTube encoder output and test the stream
Enable live streaming on your YouTube channel before the intended launch. YouTube notes that first-time activation can take up to 24 hours. Create or configure a stream in Live Control Room, copy its stream key, and enter it in OBS’s streaming settings. Treat the key like a password: do not put it in a screenshot, shell history, source file or shared log. YouTube’s encoder setup instructions explain the workflow; check them for the current interface and channel requirements.
Select YouTube’s RTMPS ingest option. YouTube recommends RTMPS, the secure extension of RTMP. Then choose the output row that matches your actual codec, resolution and frame rate rather than copying a setting because it is common in a tutorial. For standard SDR H.264, YouTube’s live encoder settings table gives these examples:
| Standard SDR H.264 output | Recommended video bitrate |
|---|---|
| 720p at 30 fps or 60 fps | 3 Mbps |
| 1080p at 30 fps | 5 Mbps |
| 1080p at 60 fps | 6 Mbps |
YouTube recommends constant bitrate (CBR) and a two-second keyframe interval, with an interval no longer than four seconds. Its table also gives guidance for other codecs and output formats; choose the matching entry if you are not using standard SDR H.264. For stereo audio, the page recommends AAC or MP3 and a 128 Kbps bitrate. These are YouTube’s recommendations, not a guarantee that the VM can encode or deliver the selected stream reliably.
In OBS, check the streaming service, stream key, encoder, output resolution, frame rate, bitrate, rate control and keyframe interval. Match the settings to the capabilities of your content and instance. A 1080p60 output takes more work than a 720p output; a complex scene may also need more CPU than a simple loop. If the encoder cannot keep up, reduce the workload or output target and test again rather than assuming a network change will solve encoding lag.
Start with a private or unlisted test stream. Confirm that the preview appears in Live Control Room, audio is present and synchronised, and the expected scene is visible. Watch OBS’s rendering and encoding indicators while the VM is under realistic load. Let the test run long enough to expose issues that only appear after a session has been active, but do not treat one successful session as proof of long-term uptime.
Record what you tested: image and shape, region, display arrangement, OBS version, scene, encoder, output settings, stream duration, and any dropped frames or connection interruptions. If you change the scene, upgrade OBS, alter the Ubuntu image or move regions, rerun the relevant checks. For channels built around a podcast or recorded material, turning a podcast RSS feed into a YouTube Live stream is a separate content workflow; it does not remove the need to validate the VM’s display and network path.
Plan for continuous operation without assuming uptime
A 24/7 goal adds failure modes beyond ordinary streaming: the VM can reboot, OBS can exit, the display session can disappear, the route to YouTube can fail, or a key or scene can be changed incorrectly. No reviewed official source establishes an end-to-end OCI, OBS and YouTube setup that survives every one of those cases. Frame continuous operation as an intended pattern, then test the recovery behaviour that matters to your channel.
Document how OBS is launched and what should restart it. That might be a desktop-session startup method or a process supervisor, but the choice must fit the display arrangement and should be tested rather than copied as a guarantee. Test the failures you expect to handle: process exit, VM reboot, administration logout, network interruption and return of YouTube ingest. For each, note whether the stream resumes automatically, needs an operator, or requires a new action in Live Control Room.
Keep logs and an alerting path that do not expose the stream key. Decide who checks the channel after an alert and what they should verify first: VM reachability, OBS process and display, outbound connectivity, and YouTube’s incoming preview. A documented manual recovery procedure is better than an automatic restart that silently loops while the stream remains absent.
The trade-off is operational control versus maintenance. With OBS on your own VM, you can build and adjust scenes directly, but you are responsible for the Ubuntu image, graphical session, networking, process recovery and capacity checks. If your real need is to leave a recorded video live while your computer is off, a cloud workflow that accepts an upload and runs the broadcast may remove the specific burden of maintaining OBS and its display session; StreamNeo is built for that uploaded-file-to-YouTube workflow. It is YouTube-only, so a need to send to other destinations or to operate OBS scenes directly may point you back to a VM or another arrangement.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
How do I run OBS on an Ubuntu VPS?
Install OBS using instructions that cover your chosen Ubuntu release, then ensure the VM has a usable X Window System or Wayland display and OpenGL 3.3. Configure OCI networking for restricted administration and outbound access, then test the complete stream path to YouTube from that instance.
Can OBS run headless on a cloud server?
A shell-only server should not be assumed to meet OBS’s Linux display requirements. You need a supported display/session arrangement and must test it across logout and reboot; official OBS requirements do not prescribe a universal OCI virtual-display setup.
How do I stream to YouTube from OBS?
Enable live streaming on the channel, create a stream in Live Control Room, add the stream key in OBS, and select YouTube RTMPS ingest. Match the encoder settings to YouTube’s current table and confirm a private or unlisted test arrives in Live Control Room before broadcasting publicly.
How can I keep an OBS stream running 24/7?
Treat 24/7 as an operating goal, not a guaranteed result. Test OBS startup, process restart, display-session behaviour, network recovery and VM reboot on your chosen setup, and document which failures need a person to intervene.