To run Wowza Streaming Engine on Google Compute Engine, the documented starting point is Wowza’s Linux image in Google Cloud Marketplace. You launch it into a Google Cloud project as a Compute Engine VM, then check the deployment details, licensing, firewall access and connection before sending real traffic.
Treat the Marketplace listing and console instructions as current snapshots, not permanent facts. Wowza’s guide, updated 22 July 2026, describes an image with Streaming Engine 4.11.3; verify the live listing before you deploy because image contents and interface steps can change.
Confirm the Wowza product and Google Cloud project
This guide covers Wowza Streaming Engine deployed from the Linux image in Google Cloud Marketplace. It is not a general guide to every Wowza product, a manual installation on a blank VM, or a method for turning a YouTube channel into a 24/7 broadcast. Confirm that Streaming Engine fits the job you have in mind before creating cloud resources.
You need a Google account with access to Google Cloud and a project in which you are allowed to create a VM and use the resources required by the deployment. You can select an existing project or create one, but make sure you understand who owns it and who can administer its resources. Google’s Cloud IAM roles documentation is the place to check current role requirements; the permissions needed can depend on your organisation’s policies and the deployment method.
It helps to separate the outcomes you are trying to achieve. Deploying means Google has created the cloud resources. Licensing means the Wowza software is permitted to run under the offer you selected. Network reachability means your chosen clients can reach the VM over the protocols you actually use. A successful first connection confirms that the service responds, but does not prove that every intended workflow is configured correctly.
Write down the intended workflow before you click Launch. A live application without server-side recording has different storage needs from a service that records, supports DVR, or serves video on demand. Your delivery protocol matters too: RTMP, RTSP, HTTP-based playback and RTP over UDP do not all use the same network paths. For a broader view of the trade-offs between a cloud machine and a local always-on computer, see the options for running a 24/7 YouTube stream from a mini PC or cloud server.
Review the Marketplace image and current version
Open the Wowza Streaming Engine product listing in Google Cloud Marketplace and read the listing that is live at the time you deploy. The Marketplace route is the preconfigured path documented by Wowza: it supplies a Linux image intended to run Streaming Engine, rather than asking you to assemble an installation on a generic operating system.
Wowza’s setup guide, updated 22 July 2026, says its preconfigured image runs Streaming Engine 4.11.3. That is a dated statement about the image described in that guide, not a promise that a listing opened later will contain the same version. Check the listing’s version, supported options and deployment instructions for yourself. If the version or steps differ from this article, follow the current listing and documentation rather than trying to force an older screen sequence.
Read the offer details before proceeding, including the software and cloud charges, support information and any terms shown in the current flow. The research for this guide does not provide a current price, and VM runtime, disk and bandwidth can also affect your bill. Do not use an old screenshot or another person’s estimate as a substitute for the live listing and your project’s cost information.
The documented Marketplace offer embeds the Wowza licence in the image and has Google manage billing for running instance time and bandwidth. Wowza’s guide says charges begin once deployment is complete and describes no separate monthly Wowza invoice for Streaming Engine usage under that offer. Reconfirm the terms on the current listing: licensing and billing arrangements are attributes of the specific offer, not facts to carry over to a different installation or a future listing.
There are other possible deployment approaches, including separately licensed software on a VM, but the material covered here documents the Marketplace route. Do not assume a manual install has the same licensing or billing treatment. If your organisation needs a particular licence arrangement, version, or software configuration, resolve that requirement before launching an image that may not match it.
Deploy a Compute Engine VM
From the current product listing, use its launch action and review each configuration page before creating the deployment. The console may change its labels, order or defaults. The essential task is to understand what resources the deployment will create, which project receives them, and which network and storage choices it applies. Wowza says the Google Cloud console is the more user-friendly provisioning route; installing the gcloud CLI is optional for this workflow.
Choose the project and region deliberately, then review the VM and storage options offered by the listing. This article does not prescribe a machine size: there is no universal shape that suits every streaming application, audience, recording pattern or budget. Start from the demands of your intended workload and the options currently offered, then monitor the deployment against actual use. Do not treat a machine-size example found elsewhere as a capacity guarantee.
Storage depends on what the instance must retain or serve. Wowza says a standard hard drive can be enough for live applications that do not record on the server. For recording, DVR or VOD, it suggests SSD for caching or direct server recordings. The suitable amount depends on such things as the recording volume, bitrate, retention period and workflow, so estimate those needs rather than choosing a made-up universal capacity. Wowza also documents Media Cache as an option for using Google Cloud Storage to store and retrieve content.
Before finalising, check the network choices as well as the machine. Marketplace deployments may offer firewall selections for common streaming and management ports. Selecting them without a use case can make the VM reachable more broadly than you intended; leaving out a required protocol can make a correctly deployed service appear broken. The next sections separate those checks so you can identify what failed rather than changing several settings at once.
When the listing and configuration make sense, submit the deployment. Note the deployment name and wait for its status in the console rather than assuming that a click has created a ready-to-use service. Do not publish generated URLs or credentials in a public checklist: they are specific to your deployment.
Check licensing and deployment details
A VM can exist even when you have not confirmed the software offer or finished the application setup. First establish which Marketplace product and licence terms you selected. For the documented offer, Wowza says the licence is embedded in the image and Google handles charges for running instance time and bandwidth. That does not mean all Marketplace products, separate installations, or later versions have identical terms.
The current listing is the authority for the offer you are about to accept. Review software charges and cloud resource charges separately in the purchase flow and project billing information. The fact that billing is bundled through Google for the documented offer does not make the VM, storage or network use free. This article states no price because rates can change and depend on what you deploy and use.
After you deploy, Wowza’s guide directs you to the Resources tab in Solution deployments to view deployment status. Open the deployment’s Details tab for its site URL and the guide’s login instructions. Use the URL and credentials associated with that particular instance; example values in a guide are not reusable credentials. Keep access details private and store them in a place your administrators can retrieve securely.
Wowza says Engine includes email-based technical support and advises a first-time Marketplace user to follow the Suggested next steps on the Details page to register in the support portal. Its guide says completing registration is needed for email support and to request StreamLock SSL certificates. Confirm these instructions in the current details page, since the interface and eligibility can change. Support registration is separate from proving that your VM is reachable on the network.
If deployment status reports a problem, begin with the deployment’s own status and messages. Check that you launched into the intended project and that the expected resources were created. Avoid deleting and recreating resources until you understand what is incomplete; a partially created deployment can still have billing implications, and the current Google Cloud console will show which resources exist.
Configure network access and firewall rules
A service can be installed and running while remaining unreachable to a client. Firewall rules need to match the protocols used by your application, and source ranges should be limited to the people or systems that need access. Wowza’s Marketplace guide warns: “Creating certain firewall rules may expose your instance to the internet.” Treat that as a security decision, not a box to tick simply because it appears in a deployment flow.
Wowza lists common ports for its Linux Marketplace setup. Use this table as a guide to what each rule is for, then verify the current Wowza documentation and your selected workflow before changing rules. Opening a port does not by itself configure an application to use that protocol.
| Traffic or purpose | Protocol and port | When to consider it |
|---|---|---|
| RTMP streaming | TCP 1935 | If your encoder or source sends RTMP to the Engine instance. |
| RTSP streaming | TCP 554 | Only if the workflow uses RTSP; Wowza says this can be disabled when RTSP is not used. |
| HTTP and HTTPS | TCP 80 and TCP 443 | For the HTTP/HTTPS uses required by your application; confirm the exact delivery path. |
| Engine Manager | TCP 8086–8088 | For administration; restrict access to trusted administrator addresses or keep it private. |
| RTP over UDP | UDP 6970–9999 | Only when the chosen workflow needs RTP/UDP. |
Wowza’s general Streaming Engine port requirements include UDP 6970–9999 for RTP. Its Marketplace setup guide lists TCP 1935 for RTMP, TCP 554 for RTSP, HTTP/HTTPS options, and TCP 8086–8088 for Engine Manager. Those are documented requirements and examples, not a direction to expose every listed port to every source. A browser-based playback path, an encoder, and an administrator do not necessarily need the same access.
Management ports deserve particular care. Do not leave Engine Manager open to the whole internet simply because it makes an initial test convenient. Use private access or limit allowed sources to trusted administrator addresses, and keep the streaming endpoints separate from management access where your network design permits. If your IP address changes or administrators work from different networks, plan a controlled access method instead of widening the rule without review.
Wowza also notes TCP 80 for HLS, MPEG-DASH and RTMPT, and says inbound HTTP allows its licensing server to confirm licence validity. Consult the current Wowza network and port guidance before changing firewall or outbound settings to troubleshoot licensing. Do not assume that opening more inbound ports fixes a licence or application configuration issue.
The firewall options in a Marketplace deployment can expose the instance to the internet, depending on what you select. After deployment, inspect the effective rules in the Google Cloud project rather than relying only on what you remember selecting. For a public stream, expose only the endpoints required by clients; for administration, use a narrower source range. If you are unsure which endpoint the workflow actually needs, test with a controlled client before broadening access.
Connect to and verify the deployment
Start with the deployment Details tab’s site URL and Wowza’s current login instructions. If the deployment is still being created, wait for its status to complete before treating a connection failure as an application problem. When you reach Engine Manager, use the credentials issued for that deployment and confirm that you can view the running service. Do not substitute credentials copied from a tutorial.
Test one layer at a time. First, establish that the deployment is complete and that the VM is running. Next, check that the client can reach the chosen address and port from its actual network. Then check that the protocol and application settings on the sending or playback side match the Wowza configuration. A browser URL failing to load does not prove that RTMP ingest is unavailable, just as a reachable management page does not prove that a video source can publish successfully.
For a sending test, use a source configured for the protocol and endpoint you intend to use, and verify that the application receives it in Engine Manager. For playback, use a client appropriate to the output format and verify the stream from outside the VM as well as from an administrator network. This catches cases where a private route works for you but the intended audience cannot reach it. Avoid using a real public event or long-running channel as the first test of an unverified configuration.
If a first connection fails, check the likely layers in order: deployment status and URL; whether the service is running; whether the client uses the right protocol and port; then the applicable firewall source and destination rules. Confirm that DNS or an address has not been copied incorrectly. Change one setting at a time and repeat the test, so you know which change resolved the problem. For planning a separate always-on YouTube workflow, the article on sending a video playlist to YouTube Live with GStreamer covers a different publishing path; it does not configure Wowza on GCE.
A successful first test is a starting point, not evidence that the deployment will meet every production requirement. If you record, verify that the recording lands where expected and that available storage suits your retention plan. If you use RTP/UDP, test that exact path rather than assuming the TCP test covers it. Keep notes on the deployment name, selected protocols, restricted admin access and test result so another administrator can repeat the checks.
Decide whether one VM is enough
For an initial deployment, one VM is easier to understand and diagnose than a multi-machine design. Do not add load balancing simply because the application is live. First determine whether the current instance meets the audience and delivery requirements you actually observe, and whether the desired workflow needs a different region or architecture.
Wowza documents a Google Cloud design with one origin VM and multiple edge VMs in a repeater configuration. In that arrangement, one edge server runs the Dynamic Load Balancing AddOn to distribute connections among the edge instances. Wowza describes this as useful when one origin cannot handle the audience load or when delivery across regions is wanted. It is an architectural step with additional software and network configuration, not a required setting for every first deployment.
If you are considering this design, work from Wowza’s current Google Cloud load-balancing guide and verify the current add-on, licence and topology requirements. Do not infer a capacity figure from the number of VMs: this guide has no benchmark or sizing formula. Measure the workload and plan the added operational work before building a second tier.
The practical comparison is between a simple starting point and a more involved topology, not between a universally right and wrong choice. A single VM keeps configuration and fault diagnosis contained. Origin-and-edge deployment introduces coordination and more places to check, but may suit a workload whose audience or regional delivery needs justify it. Revisit the design using observed behaviour rather than guessing at future demand.
Keep the operating plan separate from the Wowza setup
Wowza Streaming Engine on GCE is a way to host streaming software; it is not itself a finished 24/7 YouTube channel. A YouTube workflow has its own source, stream key, encoding, content and channel checks. Do not assume that deploying Wowza fulfils YouTube’s live-stream requirements or that a successful connection to Engine means YouTube is receiving a broadcast.
If your actual goal is an always-on channel built from a prepared video, decide whether you need a configurable streaming application or simply need a file to keep broadcasting. A prepared loop has different operational trade-offs from a live encoder and ingest server. The guide to preparing videos for an always-on YouTube stream can help with the source-file side, while this article concerns the Wowza deployment path on Google Cloud.
Keep the first production plan modest and observable. Record what should happen when the source stops, who can access administration, where recordings are stored if applicable, and who will verify the channel after a change. A small test with the intended protocol and a controlled audience can reveal configuration gaps without making assumptions about uptime or audience capacity.
Cloud deployment also has ongoing cost and support considerations. Review the current Marketplace listing and your project billing information, and keep cloud charges distinct from any other operating costs. If reliable overnight operation is the main concern, include a way to notice a failed stream and a person who knows how to respond; no deployment guide can guarantee that a particular configuration will never need attention.
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 the Marketplace image always run Wowza Streaming Engine 4.11.3?
No. Wowza’s setup guide updated 22 July 2026 describes a preconfigured image running 4.11.3, but the image and listing can change. Check the live Marketplace listing and current instructions before deployment.
Are the licence and VM charges billed separately?
For the Marketplace offer described by Wowza, the licence is embedded in the image and Google manages billing for running instance time and bandwidth. Confirm the current offer terms before launch, and review cloud resource charges separately from any other costs; this article does not state a price.
Which firewall ports should I open?
Only open the ports needed by the protocols and administration workflow you will use. Wowza documents TCP 1935 for RTMP, TCP 554 for RTSP, TCP 80 and 443 for HTTP/HTTPS uses, TCP 8086–8088 for Engine Manager, and UDP 6970–9999 for RTP; restrict management access and verify current guidance.
What should I check if Engine Manager opens but streaming does not work?
A reachable management page confirms only that the management route works. Check that the sender and application use the intended protocol and endpoint, then verify the relevant firewall rule and confirm that the application receives the source. Test the playback or delivery path separately from administration.