To run a 24/7 YouTube stream from India on Hetzner Cloud, run an encoder on a cloud server and send its output directly to YouTube Live using RTMPS over port 443. You do not need Owncast just to relay a cloud-generated feed to YouTube.
The practical work is choosing an instance and region by testing rather than guessing, matching encoder settings to the source, protecting the stream key, and supervising the process. A stream intended to stay live continuously can still be interrupted by a failed process, a network route, or a YouTube ingest issue, so build in monitoring and recovery rather than assuming a server size or location guarantees continuity.
Choose a direct-to-YouTube architecture
The basic path is source file or live composition → encoder on Hetzner Cloud → YouTube Live. The encoder creates the video and audio stream, then publishes it to the ingest address and key supplied by YouTube. If YouTube is your only destination, this is the simplest architecture to operate: there is one publishing process and one destination to monitor.
Hetzner also documents an installable Owncast app. Owncast is a separate self-hosted streaming and chat service; it is optional, not a required step between your encoder and YouTube. Consider it only if you have a reason to run your own viewing or chat endpoint as well. Adding it otherwise creates another service, configuration and failure point without making a direct YouTube stream possible in a way it was not before.
The source matters to the server choice. A video loop that is already encoded may need little ongoing processing if it can be passed through or sent without expensive transformations. A camera feed needs capture and encoding, while a composition with overlays, scenes, multiple sources or effects may demand substantially more CPU or a different encoding approach. The right server therefore depends on what the encoder must do, not simply on the fact that the channel runs all day.
If you are considering several channels from one machine, first separate the resource and failure questions: each encoder consumes resources and a shared host can affect multiple broadcasts. The guide to running separate YouTube streams from one VPS with FFmpeg covers that arrangement. For one channel, keep the first deployment deliberately simple so you can distinguish source problems from encoding, firewall or ingest problems.
Enable YouTube Live and prepare the stream
Before configuring the server, confirm that the channel can go live. YouTube says live streaming requires channel verification and that the channel must not have had live-streaming restrictions in the previous 90 days. Check the current YouTube Help instructions for getting started with live streaming, because channel requirements and interface details can change.
In YouTube Studio, create or schedule the live stream in the Live Control Room and select the streaming workflow. YouTube provides an ingest endpoint and a stream key. The endpoint identifies where the encoder publishes; the key associates the incoming feed with your stream. Do not paste the key into a public script, support post, screenshot or shared chat. YouTube describes stream keys as equivalent to a password and address, which is a useful way to treat them operationally.
Prepare the video and audio before moving to the cloud. For a loop, check that the file plays through, the audio is present at a sensible level, and the end-to-start transition is acceptable. For a camera feed or composed programme, check that the source stays available and that overlays or scene changes behave as intended. A silent or frozen source can still produce an encoder process that appears to be running, so process status alone is not proof of a healthy broadcast.
YouTube's stream may be transcoded for viewers, but that does not remove the need to send a valid, stable input. Use the platform's current encoder guidance to select resolution, frame rate, codec and bitrate together. A video loop scheduled through OBS is a different operating model from an FFmpeg process on a server, but its preparation and playback checks can help you identify source issues before moving the workload to a cloud host.
Choose a Hetzner region and server for testing
Do not assume that a particular Hetzner location is best for every Indian ISP or that geographic closeness predicts a stable route to YouTube ingest. Choose a candidate region and test the sustained connection from the actual server to the selected YouTube endpoint. A short successful login or download is not the same as a long-lived outbound stream.
Size the server according to the work performed. With a pre-encoded file, the encoder may be able to copy the existing video and audio streams rather than decode and encode every frame. That reduces processing needs, but only works when the file's format and parameters are suitable for YouTube and the intended broadcast. If you resize, change frame rate, add graphics, mix audio or encode a camera feed in software, CPU demand rises. Hardware encoding and software encoding have different compatibility and resource trade-offs, so test the actual command and source rather than choosing by a generic “24/7 streaming” label.
There is no universal server size established for this setup. Compare current server options in Hetzner's console or pricing information, including the CPU available for your encoding method, memory, disk needs for source files, outbound transfer terms, and cost. The research does not establish current prices, transfer allowances or performance from India, so verify those details on Hetzner's own site before committing. Do not treat the server's advertised network capacity as proof that the route to YouTube will remain usable.
Start with a representative workload and monitor CPU, memory, disk and network use while it runs. A static image with music is not a representative test for a multi-layer news composition. If you stream local news clips, for example, test with the same overlays, audio mixing and transitions planned for the live channel. Leave enough capacity for the encoder's peaks and operating-system tasks; if you see sustained CPU saturation or repeated encoding lag, reduce processing complexity or test a more capable instance.
For a comparison with a physical machine, weigh access and maintenance as well as compute. A local desktop can be easier to inspect and may suit a nearby operator, but it depends on power, broadband and the machine staying on. A cloud server moves those responsibilities to a remote system that you administer, but does not remove the need to secure it or check its route and process. The refurbished desktop or VPS comparison for an Indian livestream can help frame that choice without assuming that one option suits every channel.
Configure the encoder for YouTube RTMPS
For an ordinary low-latency YouTube stream, use the RTMPS ingest details supplied for the stream and send over TCP port 443. RTMPS encrypts the feed in transit to YouTube's ingest service. YouTube documents the protocol and connection details in its RTMPS setup guidance. Keep the endpoint and key as separate configuration values; use the exact endpoint YouTube provides rather than building one from memory.
YouTube supports several ingest protocols, including RTMP, RTMPS, HLS and DASH. RTMPS is the straightforward choice for this direct encoder arrangement. HLS and DASH involve different latency and codec characteristics and are not required merely because a stream runs continuously. Consult YouTube's live encoder settings and bitrates before selecting a profile, and revisit that documentation if you change resolution or frame rate.
YouTube's guidance lists H.264, H.265/HEVC and AV1 for RTMP/RTMPS, up to 60 frames per second, constant bitrate (CBR), a two-second keyframe interval recommendation with no more than four seconds, and AAC or MP3 audio. Codec availability depends on the encoder you use. A practical starting point is to select a supported codec and set the bitrate from YouTube's table for the chosen resolution and frame rate, rather than using a figure copied from another channel.
For context, YouTube recommends 10 Mbps for H.264 at 1080p30 and 17 Mbps for H.264 at 1080p60. Those are YouTube encoder recommendations for those specific settings, not Hetzner bandwidth limits or a guarantee of a good route from India. YouTube gives different recommendations for other codecs and resolutions. Leave some headroom in the measured outbound capacity and test the exact profile; if the connection cannot sustain it, a lower resolution or bitrate may be more appropriate than repeated reconnects.
With FFmpeg, keep the command configuration readable and testable. Confirm that the input maps the intended video and audio streams, the output settings match YouTube's current guidance, and the RTMPS URL points to the designated ingest. Avoid putting a real stream key directly into a command you may copy into logs, shell history or a ticket. First test with a temporary or resettable key if your workflow requires sharing configuration for review, then replace it with the protected production secret.
Protect the stream key and supervise the encoder
Treat the stream key like an account credential. Store it in a file or secret mechanism accessible only to the account that runs the encoder, with restrictive permissions. Keep it out of source control, public repositories, web pages and broadly readable environment dumps. If you have exposed it, reset the key in YouTube Studio and update the encoder configuration; simply deleting a visible copy does not invalidate a key that may already have been copied.
Hetzner makes server security and firewall configuration the customer's responsibility. Use restricted SSH administration and avoid opening inbound ports just because an encoder is publishing outwards. A direct RTMPS stream needs outbound TCP 443. Hetzner Cloud Firewalls deny inbound traffic unless you explicitly allow it, while outbound traffic is allowed by default if you have not created outbound rules. If you add explicit egress rules, allow the DNS and ingest traffic your host needs as well as TCP 443. Check the current Hetzner Cloud Firewall documentation for its behaviour and configuration.
Run the encoder under a service supervisor rather than an interactive shell that disappears when you disconnect. Configure the supervisor to start the process after a server reboot and restart it if it exits unexpectedly, while avoiding a rapid restart loop that hides a bad configuration. Ensure logs are retained somewhere you can inspect. A restart policy can recover from a process exit; it cannot correct an invalid key, a corrupt source file or a blocked network route.
Separate the encoder's operational account from administrative access where practical, and give it only the permissions it needs to read the source and write logs. Keep the server patched and the SSH path controlled. A cloud firewall is useful for limiting network access but does not replace host account security, application updates or secret handling.
For unattended operation, define who receives an alert and what they should check first. A useful runbook records the stream name, server access route, service name, log location, key-reset procedure and steps to confirm the live preview in YouTube Studio. Do not put the key itself in that runbook. If someone else may be on call, test that they can diagnose a stopped encoder without exposing the credential.
Monitor the feed and test failure recovery
A running process is only one signal. Monitor the encoder's exit status and logs, server resource use, outbound connectivity and YouTube's stream health. YouTube advises testing before the stream with representative motion and audio and watching stream health during the event. Use its encoder guidance as the reference for the current health indicators and preflight advice.
Before leaving the channel unattended, run a test with the same file or live composition, settings and destination that you plan to use. Watch the YouTube preview, listen for audio, look for dropped frames or ingest warnings, and confirm that the picture remains in motion where expected. A static devotional image with a soundtrack and a fast-moving news montage stress different parts of the workflow. Test the actual format, not just a small sample that avoids the difficult section of a long source file.
Then rehearse a controlled failure. Stop the encoder service and confirm that the supervisor restarts it; restart the server and confirm that the service starts again; inspect logs after each event. Confirm that the YouTube broadcast recovers in the way you intend and that an operator can tell the difference between a missing process and an ingest or source problem. Do this during a planned test window, not by deliberately interrupting a live audience stream.
For route testing, use a sustained test from the selected server and observe whether the stream remains stable at the intended bitrate. If a route or ISP behaves differently at another time, test again before relying on it for an important schedule. A Hetzner region that works well for one Indian connection is not evidence that it will work equally well from another ISP, city or server configuration.
Set realistic continuity expectations. Hetzner's German Cloud Server SLA page describes a 99.9% monthly availability target for each Cloud Server, measured by calendar month and subject to the SLA's terms. That is a monthly target, not a promise of no interruption, and it does not cover every application, configuration, ingest or network failure along the path to YouTube. Check the current Hetzner Cloud Server SLA and plan for recovery rather than treating a single VPS as an uninterrupted broadcast guarantee.
If repeated disconnects occur, isolate the layer before changing several things at once. Check whether the encoder process exited, whether the source stopped producing frames, whether the server can still reach the endpoint, and whether YouTube reports an ingest issue. For an India-specific checklist of symptoms and troubleshooting, see why a live stream can keep disconnecting on YouTube in India. Record the time and relevant log messages so that a change to bitrate, region or source can be evaluated rather than guessed.
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
Do I need Owncast to send a stream from Hetzner to YouTube?
No. An encoder on the Hetzner server can publish directly to YouTube Live using the endpoint and key provided in YouTube Studio. Owncast is an optional, separate service if you also want a self-hosted streaming or chat endpoint.
Why use RTMPS on port 443?
RTMPS encrypts the stream in transit to YouTube and uses the port specified in YouTube's RTMPS guidance. Port 443 is the direct choice for this setup; if you restrict outbound traffic with firewall rules, make sure the encoder can reach the ingest endpoint and that required DNS resolution also works.
What Hetzner server size should I choose?
There is no single size for every stream. A pre-encoded file loop, a camera feed and a composition with graphics or multiple sources impose different workloads, so test the real encoder settings and source while watching resource use before settling on an instance.
Can I guarantee a 24/7 stream from India?
No. The stream depends on the source, encoder, server, route from your chosen region, YouTube ingest and recovery process. Test the actual path and prepare monitoring and restart procedures, but do not treat a server location or monthly availability target as a guarantee of uninterrupted live output.