To run recorded church services as a continuous YouTube Live stream from Amazon Lightsail, you need an eligible channel, permission to broadcast every part of the recordings, and an encoder process that sends the files to YouTube. Lightsail can host that process, but neither a particular instance size nor a generic restart recipe guarantees that your stream will keep running.
Treat this as an operating workflow to build and validate, not a copy-and-paste configuration. Test the actual recordings, encoder settings, network transfer and recovery behaviour before relying on the channel overnight.
Check YouTube eligibility and rights first
YouTube requires a channel to be verified and to have no live-streaming restrictions in the previous 90 days. If live streaming has not been enabled before, activation can take up to 24 hours, so do not leave that step until the day you plan to launch. Review YouTube’s live-streaming eligibility and setup guidance and its encoder workflow in the channel account you intend to use.
Eligibility is only permission to use the feature; it says nothing about the rights to the programme. A recorded service may contain a sermon, readings, slides, congregational singing, a choir, instrumental music, recorded backing tracks and video captured by someone else. Rights can differ for each component and for the recording as a whole. Permission to use a song in a room, or to include it in a local recording, does not by itself establish permission to retransmit it on YouTube Live.
Make an inventory before putting files into a continuous loop. For each recording, note who created it, who performed or supplied the music, whether any third-party material appears, what licence or written permission covers it, and whether that permission covers continuous online live transmission and any resulting archive. If the answer is unclear, seek advice from the relevant rights holder or your organisation’s adviser rather than assuming that church use or attribution is enough.
YouTube says it scans live streams for third-party content. A matched stream can be interrupted or terminated, and an archive may receive a Content ID claim. Its copyright guidance for live streams and livestream terms explain the platform’s position; check the current official pages and your own permissions before broadcast. A prior successful test does not establish rights to use the material later or prevent a later match.
If your service uses a mix of original speech and licensed or uncertain music, consider preparing a version with only material you have cleared for this use. Keep records of permissions alongside the media files so another volunteer can check them before replacing or adding content. For a broader discussion of claims and source material, see this guide to copyright considerations for a continuous stream; the particulars for church recordings still need to be checked with the relevant rights holders.
Choose Lightsail for the measured workload
A Lightsail bundle combines compute, memory, storage and a monthly data-transfer allowance. The encoder workload is not just a matter of keeping a file online: the process must read the selected media, encode or copy its video and audio, and sustain an outbound connection. The resources needed depend on the file format, output resolution, frame rate, encoder and whether the workflow re-encodes the material.
Do not infer capacity from the name or price of a bundle. AWS lists bundles by region and configuration, but the smallest or least expensive listing is not evidence that it can encode your particular service. Start with a candidate instance, run a realistic test using the intended files and settings, and observe CPU and memory while the output is active. Leave room for the operating system and any monitoring or file-handling tasks. If the process runs close to its resource limits, choose a different configuration or simplify the encode, then test again.
A useful test uses the longest or most demanding recording in the planned rotation, not only a short, quiet clip. Watch whether the encoder keeps pace, whether audio remains present, and whether the video reaches YouTube without health warnings. A VPS can remove reliance on a church computer and the building’s local connection, but it does not remove dependence on the VPS process, its resources, the account and YouTube ingest.
Also consider where the media will live. A file needs enough storage for the intended playlist, while the operating system and logs need space as well. Keep an original copy elsewhere; a VPS working directory should not become the only copy of a church archive. AWS’s Lightsail bundle documentation is the primary place to check the current bundle details for your region.
Secure the VPS and prepare the media
Use an administrator account and SSH access deliberately. Where practical, restrict inbound SSH (TCP port 22) to the administrator’s current source IP range instead of exposing it broadly. Lightsail instance firewall rules govern inbound public-IP traffic; outbound traffic is allowed, which is the direction the encoder needs to send its feed to YouTube. Do not open inbound ports for a service your design does not use. If IPv6 is enabled, inspect its rules separately from IPv4. AWS explains this behaviour in its Lightsail firewall documentation.
Protect login credentials and the files that contain them. Use an SSH key where appropriate, keep private keys off shared machines, and remove access that a former volunteer no longer needs. Avoid putting passwords or stream keys in shell history, screenshots, shared notes or logs. If a secret is exposed, replace it rather than relying on obscurity.
Prepare a tidy media folder with clear filenames and an explicit rotation order. Check that every item plays from beginning to end, has the intended audio track, and has a duration that makes sense in a continuous channel. Test file permissions as the account that will run the encoder, not only as the administrator who uploaded them. Keep a record of which files are approved for broadcast and who can add replacements. This reduces the chance that a newly uploaded, uncleared file slips into the playlist.
If you have previously run the same files from a local computer, do not assume that the VPS will behave identically. A comparison of the different connection dependencies is covered in streaming a YouTube playlist from a local broadband connection. The key difference here is that Lightsail sends the stream from the cloud, while you still need secure access and a tested process to manage the files.
Create the YouTube Live stream and protect its key
In YouTube Studio, open Live Control Room and create or select a live stream. YouTube’s encoder workflow provides a stream URL and stream key; the VPS encoder uses these to send its feed to the matching YouTube destination. Follow the current YouTube instructions for managing live-stream settings rather than copying values from an old note or a different channel.
Treat the stream key like a password. Anyone who has it may be able to send a feed to that stream. Do not publish it in a public configuration file or expose it in a tutorial screenshot. Keep it in a restricted configuration location available only to the account running the encoder, and ensure diagnostic output does not print it. If it is disclosed, reset it in YouTube Studio and update the encoder configuration.
First test with a private or otherwise appropriately limited stream setting, and check both picture and sound in Live Control Room. Confirm that the right stream is selected, that the feed is arriving, and that the stream health display has no unresolved warning. Avoid starting a public broadcast until you know what viewers will see and hear, and have checked the title, description and audience settings in Studio.
The stream key does not make an ordinary file into a live programme by itself. You need a process that reads the media in the order you intend, sends a paced live output, and handles the transition between recordings. A playlist approach has separate design decisions; this guide to streaming a video playlist with FFmpeg is a useful companion, but validate any commands against the software and operating system you actually use.
Configure and test a paced encoder workflow
A file can be read faster than real time, so the workflow must pace its output as a live stream. It also needs a defined way to select the next recording, deal with a file that cannot be opened, and avoid an unintended gap or abrupt change in sound. These are design requirements, not proof that a particular FFmpeg command, service manager or retry setting will work on your Lightsail instance.
For YouTube ingest, its current encoder recommendations include H.264 video with constant bitrate (CBR) and a two-second keyframe interval. The recommended H.264 video bitrate depends on output resolution and frame rate: for example, YouTube lists 5 Mbps for 1080p at 30 frames per second and 3 Mbps for 720p at 30 frames per second. These are video figures; account for audio and do not treat one row as suitable for every source. Check the current YouTube encoder settings table and choose the row that matches the output you intend to send. YouTube also recommends RTMPS for encrypted ingest.
The source recording and output do not necessarily need the same properties, but converting them can add processing work. If the media is already compatible with the chosen output, a workflow that avoids unnecessary re-encoding may reduce the load; whether that is viable depends on the files and tool settings. Test the whole path rather than assuming a preset is appropriate. YouTube’s streaming tips advise leaving network headroom and monitoring stream health.
A test should last long enough to exercise the operational transitions, not merely show that a single file can connect. Check the opening, a file change, a longer section, and what happens when the encoder process is deliberately stopped and started under supervision. Inspect logs and YouTube’s health messages. Confirm that video and audio both arrive, that the output remains paced, and that the rotation behaves as intended. These checks are for your chosen setup; they do not establish automatic recovery or guarantee an overnight broadcast.
Document the exact versions, settings, file order and steps that worked in your own test. Mark unvalidated commands as examples rather than procedures. For a production channel, have another responsible person review the restart and key-handling process so recovery does not depend on one volunteer remembering an undocumented sequence. StreamNeo addresses the specific burden of maintaining a self-managed encoder process by letting you upload a video, provide the YouTube stream key and leave the computer off, but you still need to verify rights and YouTube settings for your channel.
Estimate outbound data and review hosting costs
The stream consumes outbound transfer continuously. A simple estimate starts with the total bitrate actually sent, multiplies by the number of seconds streamed, and converts bits to bytes. At a constant 5 Mbps, video alone is about 54 GB per day using decimal gigabytes: 5,000,000 bits per second multiplied by 86,400 seconds, divided by eight bits per byte and one billion bytes per GB. Audio, protocol overhead, retries and other traffic add to that figure, so it is a planning calculation rather than a precise bill forecast.
| Approximate video bitrate | Video data per day, decimal GB | What to bear in mind |
|---|---|---|
| 3 Mbps | 32.4 GB | Example for a YouTube-recommended 720p30 H.264 output; audio and overhead are additional. |
| 5 Mbps | 54 GB | Example for a YouTube-recommended 1080p30 H.264 output; audio and overhead are additional. |
| 6 Mbps | 64.8 GB | Example for a YouTube-recommended 1080p60 H.264 output; audio and overhead are additional. |
The table applies the same arithmetic to video bitrate alone; it is not a promise that your stream will use exactly those amounts. Multiply the daily estimate by the days you expect to run the stream, then compare the result with the transfer allowance for the Lightsail region and plan you are considering. AWS says inbound and outbound traffic count towards the allowance, while excess-transfer charges apply to outbound data. Allowances and applicable charges are plan- and region-dependent, so check AWS’s current transfer allowance guidance and pricing before launch.
Lightsail bundles combine compute, memory, storage and transfer; a lower bundle charge does not make an unsuitable encoder workload a good fit. AWS describes its billing as hourly up to a monthly price ceiling. Compare the plan’s current listed price, the regional transfer allowance, and possible excess charges against a realistic run schedule. Do not budget from a single advertised example without checking whether its region and configuration match yours. Track transfer after launch as well, because the actual bitrate, operating hours and other traffic may differ from your estimate.
If you need a stable public address for administration or DNS, AWS documents the option of attaching a static IPv4. A default public IPv4 can change when an instance is stopped and started, whereas an attached static IP remains the same; this does not keep the encoder process running. Treat address stability and process continuity as separate concerns, and check AWS’s current static IP guidance before relying on an address in your setup.
Monitor continuity, recovery and archives
A continuous broadcast needs an owner, a review routine and a recovery plan. Decide who checks the live preview and health messages, who receives an alert if the process stops, and how that person can safely restart it. Watch CPU, memory, disk space, process status and outbound traffic alongside YouTube’s view of the incoming stream. Logs should help diagnose a failure without exposing the stream key or other credentials.
Test recovery deliberately before launch: stop the encoder process, confirm how the responsible operator notices, then follow the documented restart steps and verify the feed in Live Control Room. Separately consider what happens if the instance restarts, a file is missing, disk space runs low, or the YouTube connection is interrupted. A process supervisor may be part of a design, but its presence is not evidence that restart behaviour is correct. Validate the chosen service configuration, retry behaviour and media selection on the actual instance. Do not describe an untested setup as automatically recovering.
Set a human check schedule that fits the channel’s purpose. For example, a church might arrange an evening check during the first nights, with someone available to respond if video or audio disappears. Keep a written escalation path and avoid giving every volunteer administrator access simply to make recovery easier. A guide to keeping an OBS stream running after a power cut discusses local-machine recovery; with Lightsail, the local power issue changes, but process and platform checks still matter.
Finally, decide whether YouTube should retain an archive and who reviews it. Live-stream archives can be subject to Content ID claims or other platform actions after broadcast, and the archive may remain visible unless you change its settings. Review the result for gaps, missing audio or unintended content, and ensure that the permissions for the recordings cover the way you handle any archive. A clean test feed does not settle the rights question for the full service.
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 I stream recorded services from Lightsail without leaving my computer on?
Yes, the encoder process can run on a Lightsail VPS rather than a computer in the church, so that local computer need not stay on for the broadcast. You still need to test the instance workload, secure access, monitor the feed and confirm what happens when the process or connection fails.
Does a stream key give me permission to broadcast the service?
No. The key identifies the YouTube feed; it does not grant rights to the sermon recording, music, performances, readings or other material in the programme. Confirm permissions for the intended live transmission and archive separately, and check YouTube’s current policies.
What bitrate should I choose for a recorded church service?
Choose an output resolution and frame rate that suit the source and your tested workload, then use the matching row in YouTube’s current encoder recommendations. For example, its H.264 recommendations list 3 Mbps video for 720p30 and 5 Mbps for 1080p30; audio and network headroom are additional considerations.
Will a restart service guarantee a 24/7 broadcast?
No. A supervisor may restart a process under some failure conditions, but it cannot guarantee that files, the instance, the YouTube connection or the channel will remain available. Test the actual restart path, monitor the broadcast and keep a person responsible for responding to problems.