You can install OBS Studio on an Oracle Cloud Infrastructure (OCI) Ubuntu Server instance using the Ubuntu installation route documented by OBS Project. That only installs the application: it does not establish that OBS can run without a display server, so treat a fully headless setup as an experiment that needs testing on your exact image and workload.
Before installing anything, check the Ubuntu release and the OBS version that its repository will provide. Then decide whether you need OBS’s graphical interface, a saved configuration that starts automatically, or a genuinely unattended stream; those are different requirements, and none of the documented launch options removes the display-server question.
Check the Ubuntu release and OBS version first
Start by connecting to the instance using the ubuntu account and checking the operating system release:
lsb_release -a
On OCI Ubuntu platform images, Oracle documents ubuntu as the default account, with sudo privileges; direct root login is disabled. If your instance uses a custom image, verify its account and access method instead of assuming the platform-image defaults apply. Keep the operating system name and release on hand before choosing an OBS installation path.
Compatibility is especially important if the instance is on Ubuntu 24.04. In an announcement dated June 19, 2026, OBS Project said OBS Studio 33 would no longer support Ubuntu 24.04, and encouraged users who want new major or minor releases to upgrade to Ubuntu 26.04 or later, or switch to Flatpak. Treat that as version-specific guidance, not a guarantee that every package or older OBS release behaves the same way. Check the current release notes and the repository’s candidate version before proceeding.
For a basic package check, refresh apt’s metadata and inspect what the configured sources offer:
sudo apt update
apt policy obs-studio
The apt policy output helps you identify whether a candidate is available and which source provides it. It does not prove that the package is suitable for the Ubuntu release, that its graphics dependencies will work on a minimal server, or that it can run without a display server. If the available version conflicts with your release or requirements, resolve that before creating a configuration around it.
If you are weighing an OCI Ubuntu image against another server distribution, the practical considerations in choosing a Linux distribution for an FFmpeg stream on a VPS are relevant background. OBS is not the same workload as an FFmpeg-only stream, but the operating-system choice still affects packages, support and maintenance.
Install OBS using the documented Ubuntu route
OBS Project’s Linux installation guidance provides a PPA route for Ubuntu. Once you have checked the release and confirmed that the OBS version offered is appropriate, run the documented commands:
sudo add-apt-repository ppa:obsproject/obs-studio
sudo apt update
sudo apt install obs-studio
The OBS Project Linux installation guide is the primary reference for those commands. Read its current instructions before using them: package availability and supported versions can change. Adding a repository is a system-level change, so make sure you understand which apt source is being added and keep a record of the installed package version for later troubleshooting.
If add-apt-repository is not available, do not guess at an alternate repository or paste commands from an unrelated distribution’s instructions. Check the current Ubuntu image and the OBS guide, then install any needed repository-management package only if the current guidance calls for it. When installation completes, confirm that the package is present:
dpkg-query -W obs-studio
A successful package installation is a useful first checkpoint, not a runtime test. It says that apt installed the package and its declared dependencies. It does not establish that OBS can initialise graphics, open your scene sources, access an encoder, or stay connected to YouTube unattended.
Keep the install stage separate from any attempt to make OBS start at boot. First confirm the installed version and whether the process can launch in the environment you intend to use. Only then build automation around it; otherwise, a startup script can hide the original failure behind repeated restarts.
Why a server without a desktop is a separate problem
Ubuntu Server generally gives you a command-line environment rather than a complete interactive desktop. OBS, by contrast, is a graphical application with Linux graphics requirements. Installing the application on the server does not itself supply a display server or prove that the system can create the graphics context OBS needs.
A “headless” server can mean several things: no monitor attached, no desktop environment installed, no graphical session at all, or no human logged in during streaming. These are not interchangeable. A machine without a physical monitor might still have a display server; a command-line-only install might not. Be precise about which condition you are testing before interpreting a launch result.
The OBS Project documentation lists OpenGL 3.3 or later for Linux. That is a requirement to check, not a feature that an OCI Ubuntu image automatically provides. The OBS installation guide also recommends X server version 1.18.4 or newer to avoid possible performance issues with some features. A minimal image may not have an X server, a suitable graphics stack, or all the libraries that a desktop installation would normally provide.
There are three distinct approaches worth separating. You can install a desktop or graphical session and administer it remotely; you can forward a GUI application to a local X11-compatible client; or you can try a virtual display with no desktop. The first two still involve a graphical display path, while the third is an experimental workaround rather than an OBS-documented no-display mode.
Oracle’s SSH documentation on X11 forwarding explains how a remote graphical application can be displayed on a local X11-compatible client. That page covers Oracle Linux and generic SSH behaviour; it does not validate OBS on an OCI Ubuntu image. Forwarding can help you reach a GUI for inspection, but it should not be confused with proof that OBS will operate unattended after you disconnect.
A separate machine and workflow may be more suitable if the actual need is to play a finished video continuously rather than compose scenes or use live capture sources. The distinction between a workstation-based OBS setup and a remote always-on stream is also discussed in how to keep OBS streaming after shutting down your computer. Choose based on the work you need OBS to do, not just on whether the package installs.
Check graphics and OpenGL requirements
Before testing scenes, establish what graphics support the instance and installed libraries expose. OBS’s Linux requirement is OpenGL 3.3 or later. A virtual display or remote X session may create a display endpoint, but that alone does not demonstrate that the graphics context available to OBS meets the requirement or performs acceptably.
You can inspect package and system information, but avoid treating one diagnostic command as a complete compatibility test. For example, glxinfo can report OpenGL details when a working X display and the relevant utility are available. If it reports that it cannot open a display, that may simply mean no display is configured; it is not by itself a diagnosis of every missing component. Likewise, seeing a reported version does not prove all OBS features or sources will work.
The graphics path can vary with the OCI shape, Ubuntu release, installed libraries, any virtualisation layer and the way the display is provided. Do not assume that adding a package will turn a server into a supported OBS environment. If you make changes to graphics libraries or display packages, record them and test again from a clean launch so you can distinguish a dependency problem from a scene or encoder problem.
Think about X server version separately from OpenGL. OBS Project recommends X server 1.18.4 or newer to avoid possible performance issues with some features, including fullscreen projector. The recommendation is not a statement that any system meeting that version will perform well for every workload, nor that X is all that is needed. Keep the exact OBS build, Ubuntu release, X server version and graphics details with your test notes.
This is also where it helps to decide what you actually need to see. If you only need to configure scenes once, a remotely accessible graphical session could be useful during setup, even if your eventual unattended mode remains unproven. If you need regular scene changes, monitoring or source troubleshooting, a workflow that hides all graphical access may make ordinary maintenance harder than expected.
Treat a virtual display as an experimental workaround
A common idea for a no-monitor application is to provide a virtual display. That can be a useful experiment, but the official OBS Linux installation material cited here does not provide an OBS-specific, supported headless recipe. Do not present a virtual-display configuration as a guaranteed fix or assume it will work across OBS builds, graphics stacks and sources.
The reason is that a virtual display addresses only part of the problem. OBS still has to create a graphics context using the available libraries, initialise its own interface and render the configured scenes. A source may depend on hardware, an audio device, a browser component or another facility that a basic virtual display does not supply. The encoder and sustained workload introduce further questions.
If you choose to investigate a virtual display, do it as a controlled test on a disposable or recoverable instance. Keep notes on the Ubuntu image, OBS version, display packages and configuration, graphics details, scene collection and output settings. Change one part at a time. If OBS starts only after several undocumented changes, you have a fragile local setup, not a portable recipe you can safely assume will survive package upgrades or a reboot.
Test the exact scenes you intend to use rather than an empty default window. A blank OBS window may open while a browser source, video capture source or media file fails later. Test from a fresh process, then test again after a reboot and after disconnecting your administrative session. Observe logs and the actual YouTube output; do not infer a healthy broadcast from a process that remains running.
If the experiment does not work, avoid stacking more display and graphics packages without a clear hypothesis. Re-check compatibility, package state and error messages. You may decide to use a supported graphical environment, move the workload to a different operating system or choose another broadcast method. The Docker workflow for a prerecorded YouTube Live stream may help frame an alternative when a fixed video loop, rather than OBS scenes, is the requirement; it does not make OBS headless operation more certain.
Use launch options for automation only after validation
OBS provides command-line options for selecting a saved configuration and beginning an action. Its launch parameters documentation describes options including --collection, --profile, --scene, --startstreaming and --startrecording. These can help automate a known setup, but the documentation does not describe them as a way to eliminate display-server or graphics requirements.
The sensible order is to configure and save the scene collection and profile, launch OBS successfully in the chosen environment, and verify that the intended scene and sources load. Only after that should you test the relevant launch parameters. A command that requests streaming can select an action; it cannot prove that the stream key is correct, a source is available or the graphics setup is sound.
Keep secrets out of shell history, scripts that are readable by other users, and logs. In particular, treat a YouTube stream key as a credential. Use the current YouTube guidance for managing stream keys and verify the correct stream in the relevant channel account before a live test. Do not paste a key into a public support thread or include it in diagnostic output.
For unattended operation, define what counts as recovery. A process supervisor might restart an exited application, but a restart does not necessarily restore the desired scene, repair an unavailable source, or resolve a failed connection. Test the recovery path deliberately, and decide how you will know that the public stream has resumed rather than merely that a process exists.
There is an operational trade-off here. A saved configuration with launch flags can reduce repetitive manual steps, but you still need to maintain the display and graphics dependencies, protect credentials, and inspect the stream after changes. If the system is difficult to observe remotely, a simpler playback workflow may be easier to support than a full OBS scene stack.
Validate sources, encoding and the actual broadcast
A meaningful test should resemble the real channel. Write down every source in the scene: local video files, browser sources, images, audio inputs, cameras, capture devices or any plugins. For each one, confirm that its files and dependencies are available after a reboot and that the source behaves as expected without an interactive desktop session. A scene that works on your laptop may rely on a device or path the cloud instance does not have.
Then test the encoding workload on the selected OCI shape. No source cited here establishes that a particular instance type can handle a specific resolution, frame rate, encoder or continuous workload. Hardware encoding availability, audio-device access and sustained performance depend on the instance and configuration. Do not choose settings based on an assumption that a cloud VM has the same capabilities as a desktop graphics card.
Run a private or otherwise controlled test first where practical, and inspect the received video and audio from a separate client. Check for a stable picture, correct scene, audible sound, expected transitions and any visible rendering or encoding warnings. Let the test run long enough to expose issues that do not appear immediately, then repeat after a reboot or process restart. There is no substitute for testing the actual configuration you intend to leave running.
If your stream uses pre-recorded media, make sure the source file itself is prepared appropriately. The practical considerations in choosing a CRF value for pre-recorded videos in a YouTube Live stream can help with file preparation, but a file-quality setting does not establish the server’s ability to render and encode it continuously.
On OCI, networking has more than one control point. Oracle advises checking the instance’s network security groups, subnet security lists and host firewall when investigating connectivity. Platform images default to SSH-only access. Do not open broad inbound access simply because a stream is not connecting: first determine which traffic direction and service the test requires, and compare the cloud rules with the host configuration.
Be particularly cautious about changing UFW on an OCI Ubuntu image. Oracle warns that using UFW can prevent the instance from booting unless its prescribed workaround is followed. Read the current OCI Ubuntu platform image guidance before changing firewall behaviour, and retain a recovery path. A failed reboot after a firewall change is a different problem from an OBS graphics failure.
When you have confirmed that an OBS workflow is too fragile for your unattended requirement, it is reasonable to choose a simpler design rather than keep patching it. If the need is specifically to turn an uploaded video into a YouTube live broadcast while your own computer is off, StreamNeo removes the need to keep this OBS workstation-style setup running and managed on the OCI instance.
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
Can OBS run on Ubuntu Server without a desktop?
Installing OBS on Ubuntu Server is possible using OBS Project’s Ubuntu instructions, but installation alone does not prove it can run without a display server. OBS’s Linux guidance lists OpenGL 3.3 or later, and the official material here does not give an OBS-specific supported headless recipe. Validate the exact image, build, graphics path and scenes you plan to use.
Does a virtual display make headless OBS officially supported?
No. A virtual display is an experimental workaround, not a guarantee of headless operation across OBS builds, graphics stacks or sources. Even if OBS opens, test every source, the encoder workload, reboot behaviour and the received stream.
Can OBS start streaming automatically from the command line?
OBS documents launch parameters such as --startstreaming, along with options to select a profile, scene or collection. These automate actions against a saved configuration; they do not establish that a display server is unnecessary or that the broadcast will succeed unattended. Test the full setup and protect the stream key.
What should I do if OBS 33 is needed on Ubuntu 24.04?
OBS Project’s June 19, 2026 announcement says OBS Studio 33 will no longer support Ubuntu 24.04 and points users seeking new major or minor releases towards Ubuntu 26.04 or later, or Flatpak. Check the current OBS release guidance and your OCI image before choosing a route, as package and compatibility details can change.