Installing OBS Studio on a Hetzner Cloud server involves more than installing a Linux package. OBS documents Linux display and graphics prerequisites, but the available official guidance does not confirm a headless Hetzner setup or prove that a particular instance can sustain a 24/7 stream.
Use this guide to understand the decision points, provision a server carefully, and follow OBS’s official installation route for your distribution. Treat a successful package installation as a starting point, not evidence that OBS can open, encode, connect to YouTube and keep running unattended.
Understand the limits of running OBS on a Hetzner server
OBS is a desktop application. Its Linux requirements include an OpenGL 3.3-compatible GPU and an X window system or Wayland. A command-line-only virtual machine does not automatically provide either a usable graphics path or a display session. Installing the application package therefore does not, on its own, establish that its graphical interface will start or that streaming will work.
This distinction matters because a cloud server can look suitable on paper while still lacking a prerequisite that OBS expects. Hetzner describes Cloud servers as virtual machines, and the available documentation does not specify a validated combination of virtual graphics, display software and OBS configuration for headless use. Do not assume a remote desktop, virtual display or other workaround is supported merely because it can be configured in Linux generally.
There is a second gap: opening OBS and starting a short broadcast are not the same as operating a channel continuously. OBS’s quick-start guidance recommends testing output for a few minutes; it does not provide a 24/7 recovery design. A prolonged channel needs a known way to restart the process, detect a failed broadcast, restore the display and graphics environment if it stops, and check YouTube’s live status. Those details must be verified for the actual machine and configuration.
If you mainly need to turn a prepared video into an always-on YouTube stream without keeping your own desktop running, compare that workflow with the more general continuous stream options. OBS on a VM is a possible technical direction to investigate, not a shortcut around testing and ongoing operations.
Linux prerequisites and choosing a server
Start with OBS’s Linux system requirements. The key checks are the compatible OpenGL graphics capability and a working X window system or Wayland environment. OBS also cautions that satisfying the listed requirements does not guarantee that a particular computer can stream or record. Apply that caution to a virtual server: you need to establish what graphics and display capabilities the selected instance actually exposes, not infer them from its CPU or memory allocation.
Hetzner offers different server types, including shared-resource and dedicated-resource options; dedicated instances have dedicated CPU resources according to its Cloud overview. That distinction describes resource allocation, not a recommendation that a particular type is sufficient for OBS. The research available for this guide does not establish a suitable model, a minimum capacity, or a tested configuration. Verify current specifications and any graphics or encoding capability before choosing.
Use these comparison questions rather than selecting on a headline CPU count alone:
| Check | Why it matters | What to verify before ordering |
|---|---|---|
| CPU allocation | OBS must encode and process the scene; workload depends on the content and settings. | Current CPU details and whether resources are shared or dedicated. |
| Graphics and display | OBS lists OpenGL compatibility and an X or Wayland system as Linux prerequisites. | Whether the VM exposes a suitable graphics path and how a display session would be provided. |
| Encoding path | Hardware encoding can reduce CPU workload, but availability is machine-dependent. | Whether an appropriate encoder is actually exposed to the guest; do not assume it is. |
| Public networking | A public interface is needed if the server is to connect to internet services. | Whether a Primary IP is configured and what the current IP cost is. |
| Location and traffic | The route and sustained outbound traffic can affect the practical operation and bill. | Available locations, network terms and current traffic charges on the vendor’s site. |
OBS documents hardware encoding as a way to lower CPU workload, while noting that older generations may provide lower image quality at the same bitrate. This is not proof that any particular Hetzner Cloud server provides an encoder OBS can use. If a suitable encoder is not available, the encoding work falls to the CPU, and you still need to establish that the chosen settings and workload are viable.
Hetzner’s overview distinguishes the server from its Primary IP and notes that a Primary IP is needed for an internet-connected public network interface. Account for both the need for connectivity and the associated current terms when comparing options. Do not rely on an old price, an unverified community recommendation or a server-size guess as a 24/7 sizing rule.
If you are comparing virtual machines for a continuous channel, the factors in this cloud VM specifications guide can help frame the questions. Treat any proposed size as a hypothesis to validate against OBS’s graphics requirements and the exact workload, rather than as evidence that a specific Hetzner instance will work.
Provision a Hetzner Cloud server
Hetzner’s server creation guide walks through choices including server type, location, image, networking, SSH key, firewall and backups. The labels and available products can change, so follow the live console and documentation rather than copying a screenshot from an old tutorial. Choose a Linux distribution that you intend to support and that appears in OBS’s current installation guidance.
Make the SSH-key decision before creating the instance. Hetzner notes that an SSH key cannot be added later through the Console after server creation. If you already administer machines using a key, use the right public key; if not, create one and keep the private key protected on your own device. An inaccessible server can turn even a correct OS installation into a recovery task.
Decide whether the machine needs public internet connectivity, then review the Primary IP and networking choices. The stream must be able to reach YouTube, and you will need an administrative route into the VM. Review the firewall at provisioning rather than leaving access broader than your needs. The Hetzner documentation identifies a firewall setting, but it does not supply OBS-specific rules; allow only the administration and workflow traffic you have independently confirmed is required.
Backups are worth considering before you install or configure software, particularly if recreating the environment would cost you time. A backup does not test OBS, preserve a live broadcast by itself, or replace a recovery plan. Keep a record of the chosen image, server type, network settings and the relevant SSH key identity so you can distinguish a configuration problem from a provisioning one.
Once creation completes, connect over SSH and confirm you can administer the system. Check the installed distribution and update it using that distribution’s documented maintenance process. Keep the server private to the extent your workflow allows, and avoid exposing a graphical desktop or remote-control service to the public internet without a specific, secured reason. The sources cited here do not establish the exact remote-display arrangement OBS would need.
Install OBS using its official Linux instructions
Use OBS’s Linux installation page as the source of truth for the distribution you selected. It recommends Flathub for distributions other than Ubuntu and gives an Ubuntu route using the OBS Studio PPA and apt. The page is dated 2021, so check the current linked instructions and your distribution’s support status before running commands. Do not assume a copied command from an older post still applies unchanged.
On Ubuntu, the official page’s PPA-and-apt route is the relevant starting point; confirm that the instructions still match your release, and read the repository guidance before adding it. On another distribution, follow the Flathub recommendation or the distribution-specific route linked by OBS. Installation mechanisms differ: package repositories and Flatpak have their own update and dependency behaviour. Choose one supported route for your OS rather than layering installation methods without knowing which package will launch.
A package manager reporting success answers a narrow question: it installed files according to that package source. It does not demonstrate that the machine has the graphics support, display session or encoder needed to run OBS. Nor does it demonstrate that OBS can connect to YouTube from the provisioned network. Keep those as separate checks, and do not claim success at the channel level because a command completed without an error.
Before moving on, note the installed OBS version and how it was installed, then use the same method to apply future updates. If the official page’s current instructions conflict with an older distribution guide, prefer current documentation for the selected OS and OBS rather than silently substituting commands. A reproducible record helps when you need to rebuild the VM or diagnose a change after an update.
Check installation and OBS startup
The next test is whether OBS actually starts in the environment you have configured. OBS expects a Linux display system and compatible OpenGL graphics; a bare SSH session is not by itself evidence that those prerequisites are present. If the application fails to open, capture the error and investigate the display and graphics path before changing streaming settings. The current source material does not give a Hetzner-specific procedure for supplying those prerequisites headlessly, so this guide does not present one as verified.
If OBS opens, use its Auto-Configuration Wizard as a starting point, then inspect what it selects. The wizard can help select settings for the available environment, but it cannot make unsupported virtual graphics available or guarantee that an ongoing stream will be stable. A configuration that works for a short test may behave differently under a longer workload, after a restart, or after a system update.
OBS recommends testing output for a few minutes before going live. Use a private or otherwise appropriate test destination and confirm the result in YouTube Studio. Check that video and audio arrive, that the image is the expected one, and that the stream status reports a healthy connection. If your source is a recorded programme, check the file and audio separately; practical checks such as those in this pre-live checklist catch basic omissions, but do not certify a server for unattended use.
For a long-form source, review the file and audio before streaming rather than diagnosing them after launch. If speech and picture drift out of sync, the causes may be in the media or processing chain rather than the VM itself; this audio sync troubleshooting guide is relevant to that separate problem. These checks make a short test more informative, but they remain preflight checks rather than proof of 24/7 operation.
Configure the YouTube Live connection carefully
Only work on YouTube settings after OBS can start and the display and graphics prerequisites have been verified. In YouTube Studio, follow the current live-streaming setup instructions for your channel, create or select the stream, and use the connection details shown there in OBS. Treat the stream key as a secret: do not paste it into public notes, screenshots or a shared configuration. If it is exposed, use YouTube’s current controls to replace it.
YouTube’s cited documentation here is specific to HDR streaming and describes choosing YouTube RTMPS in OBS in that context: YouTube HDR streaming guidance. It should not be used as a source for ordinary H.264 bitrate, resolution, frame-rate or keyframe settings. Check YouTube’s current encoder guidance for the stream type you are actually using before setting those values; this guide does not supply unverified numbers.
Use OBS’s output test and check the receiving end in YouTube Studio. Confirm that the intended title, visibility and stream destination are correct before a public launch. If the channel is devotional, a study station or a local information loop, also confirm that the visuals and audio are the intended programme and that you have the right material queued. A green connection indicator or a successful preview only describes the test at that moment.
A useful decision point is whether you need OBS’s scene composition and live controls, or simply need a fixed uploaded file to continue playing. OBS may suit a workflow that genuinely depends on those controls, provided you can establish a supported graphics/display environment and operation plan. For a file-led 24/7 stream, a managed approach such as StreamNeo removes the need to leave your own computer running to keep an uploaded video broadcasting, but it remains YouTube-only and does not make licensing or channel policy checks unnecessary.
Plan operations before calling it continuous
A 24/7 channel is an operating process, not just a successful launch. Before relying on a VM, decide how you will notice that the stream has stopped, who will respond, how the OBS process and its display environment will be restored, and how you will confirm that YouTube is receiving the broadcast again. The official OBS material cited here supports a short test, not an automatic restart policy, monitoring design or uptime promise.
Do not add a process supervisor or restart rule by guesswork. Automatically restarting OBS could recover from some application exits, but it would not necessarily restore a missing display session, repair a network issue, or deal with a rejected stream key. A restart loop can also conceal a persistent failure while the channel stays offline. Verify any service-management instructions against the exact Linux distribution, OBS packaging method and display arrangement, then test failure and recovery deliberately before depending on them.
Plan how you will check the stream from outside the server. A process that appears active in Linux may not mean YouTube is receiving usable video and audio. Likewise, YouTube’s live preview can show a connection while a source has frozen or become silent. Decide what you will inspect, how often you will check it, and how you will regain access if SSH or the public network path fails.
Keep updates and configuration changes controlled. Make one change at a time, then repeat the short output test and verify the result on YouTube. Record the version, settings and recovery steps that actually worked in your configuration. Do not update a working 24/7 channel casually without a maintenance window and a way to check it afterwards.
The choice may be to stop here. If you cannot verify a suitable graphics/display arrangement or cannot operate recovery checks, do not treat the VM as a proven always-on solution. Reconsider whether a desktop you can manage, a different encoding workflow, or a service built around an uploaded video better fits the channel. Choosing another route is more practical than promising uninterrupted operation from evidence that only demonstrates installation.
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
Does installing OBS on Hetzner mean it will run headlessly?
No. OBS lists a compatible OpenGL graphics capability and X window system or Wayland among its Linux prerequisites. The cited sources do not verify a headless setup for a Hetzner Cloud VM, so confirm a suitable display and graphics arrangement before relying on it.
Which Hetzner server type is enough for a 24/7 stream?
The available evidence does not establish a suitable server type or size. Compare current CPU, graphics and encoding capabilities, public networking and traffic terms, then test the actual workload; a dedicated CPU description alone is not a sizing recommendation.
Can I use OBS’s wizard as proof the stream is ready?
No. The Auto-Configuration Wizard is a starting point, and OBS recommends a short output test. Check the incoming picture and sound in YouTube Studio, and treat that test separately from a verified recovery and monitoring plan.
What should I check if OBS installs but will not open?
Check the distribution-specific install instructions and whether the VM has the Linux display system and OpenGL capability OBS expects. A successful package install does not prove those prerequisites are available; investigate the actual error and current OS documentation before changing stream settings.