Wowza Streaming Engine Manager is the browser interface for managing a Streaming Engine server, its applications and its status. To set up a live stream, first confirm that Engine is running, then configure a suitable live application, connect a compatible source and verify that the server recognises it.
Treat the settings in this guide as checkpoints, not a universal recipe: application names, credentials, publishing details, ports and protocols vary by installation. Before downloading or enabling features, check Wowza’s current supported versions and licensing information for your deployment.
Check requirements and install
Start with the machine or hosted instance on which Streaming Engine will run. Check the system requirements in Wowza’s installation and configuration guide, and confirm that the operating system and deployment method are supported. The same guide describes installation and creating administrator credentials. Its examples may show a particular release; do not treat an example version such as 4.12.0 as a guarantee that it is current. Check Wowza’s documentation and licensing terms before you download or plan around a feature.
Keep the first goal narrow: a running Engine instance that accepts one live source and can deliver it to a player. You do not need to start by configuring every capability listed in Manager. Transcoding, recording, digital rights management and other functions are separate capabilities, and whether they are available depends on the relevant installation and licence. Do not assume any of them is required for a basic ingest-and-playback check.
During installation, record the administrator username and password in a secure place. These are for managing the server, not necessarily the credentials an encoder will use to publish. That distinction matters later: an administrator account gives access to Manager, while a source account may authorise an encoder to send a stream to an application.
Once the service is installed, check whether the server responds at the documented server-version endpoint, typically http://[wowza-ip-address]:1935/ServerVersion, substituting the address for your own instance. This is a basic reachability check, not proof that an application, source or player is configured correctly. If it does not respond, confirm the Engine service state, address and network rules before moving on.
Open only the ports your workflow needs
A streaming server and its Manager need network paths, but the required ports depend on the protocols and deployment you intend to use. Wowza’s installation guide lists defaults including TCP 1935 for RTMP-family streaming, TCP 8086–8088 for administration, UDP 6970–9999 for RTP/UDP streaming, TCP 80 for HLS, MPEG-DASH and RTMPT, TCP 443 for TLS streaming such as RTMPS or HTTPS, and TCP 554 for RTSP. These are reference defaults, not a direction to open every port on every firewall.
| Purpose or protocol | Documented default ports | What to check |
|---|---|---|
| RTMP-family streaming | TCP 1935 | Confirm the encoder’s publishing protocol and the server listener. |
| Manager administration | TCP 8086–8088 | Check how the deployment exposes administration; do not expose it casually. |
| RTP over UDP | UDP 6970–9999 | Confirm the relevant UDP range is allowed along the network path. |
| HLS, MPEG-DASH or RTMPT | TCP 80 | Check whether the service is configured to use this listener. |
| TLS streaming, including RTMPS or HTTPS | TCP 443 | Confirm the selected secure protocol and listener. |
| RTSP | TCP 554 | Check the RTSP workflow and any associated transport settings. |
The ranges above come from Wowza’s documentation and may not match a customised installation. Ports cannot simply be shared between services, and a port number on a page does not establish that the corresponding protocol is enabled. Check the configured listeners and firewall rules at the server, cloud or hosting-provider level. On a home or office connection, router forwarding may also be needed; in a managed network, ask its administrator to review the path.
Separate streaming traffic from Manager access in your thinking. Wowza says Manager connections default to localhost. A public IP address alone does not make remote Manager access available or appropriate. Remote administration is its own deployment and access-control task: verify how the instance is configured, restrict access to authorised users and avoid exposing an administrative interface simply to make a browser test convenient.
If you are publishing from an encoder on a different network, test the actual route that the encoder will use. For a source at home and a server in a cloud deployment, for example, check the cloud firewall and any local network restrictions against the chosen protocol. A successful Manager login from your laptop does not prove that the encoder can reach the publishing listener.
Sign in to Streaming Engine Manager
Open the Manager address for your deployment. Wowza documents an address in the form http://[wowza-ip-address]:8088/enginemanager; substitute the server address and account for your installation. Sign in with the administrator credentials created during setup. The address and access method can differ when the service is behind a proxy, configured for secure access or restricted to local connections, so use the deployment’s own instructions rather than assuming the documented default is remotely reachable.
Manager is the browser interface for the server, applications and their status. The Manager overview describes the main areas: Server settings cover the server and virtual host, while Applications is where you work with live and video-on-demand applications. The homepage also provides connection and resource information. Think of those areas as a way to separate server configuration from the destination that will receive your source.
If the login page does not load, work through the access path before changing application settings. Confirm that the service is running, the Manager address and port match the installation, and firewall or network rules permit access from your location. If Engine responds but Manager does not, that can point to an administration-access issue rather than a publishing issue. Keep administrator credentials private and do not put them into an encoder configuration.
Choose an application for the delivery path
An application is the server-side destination for the stream. For the simplest case—a source publishing to one Wowza server that delivers directly to players—choose or create a Live Single server application. The word “live” alone is not enough to identify the right architecture; the other live application types serve different paths.
| Application type | Where the stream comes from and goes | When it fits |
|---|---|---|
| Live Single server | A source publishes to one server, which serves players directly. | A straightforward single-server ingest and delivery workflow. |
| Live Origin | An origin receives live streams for delivery to other Wowza servers. | A distribution design that uses origin and edge roles. |
| Live Edge | An edge server receives streams from an origin. | The receiving side of an origin-to-edge arrangement. |
| Live HTTP Origin | Live output is delivered into HTTP caching infrastructure. | A workflow designed around that delivery architecture. |
These are architectural distinctions, not interchangeable labels or quality levels. If you are setting up one source and one server for direct playback, a Live Single server application is usually the simpler starting point. If you are building a multi-server distribution or a caching arrangement, follow the design intended for that topology rather than choosing an application by name alone.
In Manager, inspect the Applications area and note the exact application name. It becomes part of the publishing destination, so a mismatch between the configured application and the encoder’s destination can prevent the server from associating an incoming source with the intended app. If a suitable application already exists, verify its type and settings before creating another. Keep a short record of the application name and any relevant publishing details for whoever configures the encoder.
Do not conflate this server-side destination with your YouTube channel or a YouTube stream key. This workflow is about publishing a source to Wowza Streaming Engine and having it recognise that source. A separate onward-delivery design may be needed if the eventual destination is another platform; do not infer that Manager’s live application automatically connects to YouTube.
Set source credentials and publishing details
A camera or encoder is the publishing source; the application is where that source publishes. Wowza’s publisher connection guidance says RTMP- and RTSP-based encoders must, by default, provide source username and password credentials before publishing to a live application. Source credentials are distinct from the Manager administrator login. Create or manage the source account in Server > Source Authentication, then enter the matching details in the encoder. The documented values are case-sensitive, so copy them carefully without adding spaces or changing capitalisation.
Before editing the encoder, collect the actual destination details for this installation: server address, application name, stream name or key, selected protocol and source credentials if required. These values depend on the application and source. There is no single server URL or stream key that applies to every Wowza installation. Use the Manager configuration and the deployment’s instructions; do not copy a tutorial or trial-host value into a production setup.
A source account should be treated as a publishing credential. Share it only with people and equipment that need to send video, and update the relevant encoder if the account changes. If authentication fails, check the account’s spelling and case, confirm that the encoder is configured for the intended application, and make sure it is sending with a protocol for which those credentials apply.
For a one-person setup, a software encoder such as OBS may be enough if it supports the publishing protocol and fields your application requires. A live-streaming camera or another RTMP-capable encoder may suit a hardware workflow. Compare equipment by whether it can set the server, application and stream details, use the required protocol and supply credentials—not by assuming that all devices expose the same controls. The setup and equipment guide can help you think through what you already have before buying anything; a camera is not mandatory if a suitable software encoder is available.
The Wowza OBS example is useful as a demonstration of the sort of fields a publisher may request. Treat its sample values as illustrative only. Replace them with the address, application, stream name and credentials for your installation, and check the encoder manufacturer’s documentation if a field behaves differently or is named another way.
Configure the encoder and the network path
In the encoder, select a protocol supported by both the source and the application configuration. Enter the server address and application name in the fields required by that encoder, then provide the stream name or key and source credentials where required. The layout differs by product: one encoder may combine the application and stream name in a destination field, while another presents them separately. Follow the encoder’s documentation and the values supplied by the Wowza installation rather than relying on a universal URL format.
Check the full route from source to Engine. The server must be listening for the chosen protocol, the firewall and any router must allow the relevant traffic, and the encoder must be able to reach the server address. If you use RTMP or RTSP, remember the default source-authentication requirement described above. If you choose a different protocol, verify its corresponding server and network configuration rather than assuming RTMP settings will apply.
Start with a short, controlled publishing attempt. Confirm the encoder shows that it is trying to connect, then check Manager for evidence that the server has received it. Avoid changing several unrelated settings at once: if the source does not appear, changing the protocol, credentials and application simultaneously makes the cause harder to isolate. Check one item at a time—destination, application, stream name, credentials, listener and network path—and retry.
This is also where a long-running channel creates a different operational question from a short test. A source that depends on a home computer and its encoder staying open needs that computer, power and network connection to remain available. If an always-on YouTube channel uses a prepared video rather than a live camera, a different workflow may be more appropriate; see how to send a 24/7 stream from a Windows cloud PC. StreamNeo addresses the separate problem of keeping an uploaded video broadcast running without your computer left on, but it is YouTube-only and does not replace a Wowza publishing workflow when you need Wowza to ingest a live camera or encoder.
Verify that Engine recognises the source
Starting the encoder is not proof that Engine has accepted the stream. In Manager, open Applications, select the live application and look for Incoming Streams. Wowza’s publishing example uses an Active source as the confirmation point. Check that the source is associated with the application you intended and that its status indicates an active connection. If it is absent or not active, return to the destination, authentication and network checks instead of assuming the stream is ready for viewers.
After ingestion is visible, test playback with a client using the playback details appropriate to your application and protocol. Wowza’s beginner tutorial describes using VLC as a local playback client. A successful player test helps separate “the server has accepted a source” from “a player can retrieve it”; the two checks answer different questions. If the source is active but playback fails, inspect the playback URL or protocol, application settings, firewall path and player compatibility.
Manager’s status area can also help you interpret a failure. It shows source and playback connections, along with resource information such as CPU, Java heap, memory and disk usage. Use these as diagnostic signals, not as a promise that a particular capacity is sufficient. If the source never appears, focus first on ingest details; if playback starts and then fails under load, examine the server’s resource and connection status alongside the delivery path. For a separate case involving an always-on YouTube stream stopping when a machine runs short of memory, this memory diagnosis guide covers the symptoms and checks for that different setup.
Keep notes on the configuration that actually worked: application type and name, protocol, server address, stream name, source-account handling, and the network rules involved. Do not record passwords in an openly shared checklist. These notes make it easier to distinguish a later credential change from a firewall or application change, especially when another person maintains the channel.
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 every Wowza installation use the same port and stream URL?
No. Wowza documents default ports, but the relevant listeners depend on the protocol and installation configuration. The server address, application name, stream name and publishing details are also specific to the deployment, so verify them in Manager and with the person who administers the instance.
Are Manager administrator credentials the same as source credentials?
Not necessarily. The administrator account is used to sign in to Manager, while an RTMP- or RTSP-based encoder must by default use source credentials to publish to a live application. Create or manage the source account in the appropriate Server area and enter the matching, case-sensitive details in the encoder.
Which live application should a beginner choose?
For a source publishing to one server that delivers directly to players, Live Single server is the straightforward application type. Live Origin, Live Edge and Live HTTP Origin support different distribution architectures, so use them when your delivery design calls for those roles.
How do I know the live source is really connected?
Check Applications > your live application > Incoming Streams in Manager and confirm the source is Active. Then test playback separately with a suitable client, such as VLC, using the playback details for your setup. A running encoder by itself does not confirm either ingestion or playback.