Planning Your Installation

Before installing Power Studio, decide how the complete broadcast system should be arranged. A Power Studio installation normally has three important parts:

  • the Power Studio application on one or more Windows computers;
  • the PostgreSQL database that stores station data, users, formats, playlists and settings;
  • the audio storage that contains music, jingles, commercials, voice tracks and production audio.

It is possible to start small and grow later, but planning the desired setup before the first installation avoids unnecessary rework. Moving the database, changing audio paths or redesigning the network after the station is already on air is possible, but it should be treated as a planned maintenance project.

Define The Workstation Roles

Start by naming the role of each computer.

RoleTypical purposePlanning notes
On-air playout computerRuns the live Playout Playlist, Playout Players, Automation Mode and Live Assist Mode.This is the most critical workstation. Keep it stable, predictable and focused on playout.
Central playout computerRuns central nonstop playout and can coordinate which studio is on air in a Multi Studio setup.Treat this as critical broadcast infrastructure. Document its server address, listening port, studio numbers and control-system integration.
Studio playout computerRuns a Power Studio instance in a live studio that can become the active on-air studio.Plan the studio number, audio routing, player channels, mixer control and local fallback behavior.
Production workstationUsed for library work, playlist editing, recording, voice tracking and preparation.It may use different audio routing and startup windows than the on-air computer.
Database and file serverHosts PostgreSQL and/or the shared audio storage.Recommended for larger stations and installations with several clients.
Remote or home workstationUsed with Power Sync or over VPN with Local Asset Cache for voice tracking, playlist work or maintenance.Choose the remote-audio strategy before relying on it.
Training or test workstationUsed for practice, testing and configuration checks.Use Training Mode or a separate test setup where changes must not affect on-air operation.

Use clear computer names and document them. In a multi-computer station, the computer name, database connection, audio paths, plugin mappings and Multi Studio settings all need to match the role of the machine.

Common Setups

Stand-Alone Computer

A stand-alone setup uses one computer for everything: Power Studio, PostgreSQL and audio storage. This is the simplest setup and can work for small stations, production rooms, training systems and mostly automated streams.

Use this setup only when the computer is reliable enough for the full broadcast role. If this computer is offline, both playout and the database are unavailable.

Use an SSD for Windows, Power Studio and PostgreSQL. If the audio library is large, use a second internal SSD or a high-quality internal disk for audio storage. Keep the audio files in a stable folder path that will not change after the database has been filled.

This setup is not ideal when several users need to work at the same time, when the audio library is very large, or when the station expects remote/home voice tracking.

Studio Computer With Network Clients

In a small station setup, the on-air computer runs Power Studio, PostgreSQL and the audio share. Other computers connect to the database and the same audio path to manage tracks, create playlists or record voice tracks.

This setup is easier than a dedicated server setup, but the on-air computer now also acts as a server. Make sure it has enough CPU, RAM, disk speed and network quality.

Use this setup only when the on-air computer can handle both playout and server duties without becoming fragile. If production workstations, remote users or background jobs make the on-air computer busy, consider moving PostgreSQL and audio storage to a dedicated server.

Multi-Studio Installation

A Multi Studio installation can have multiple on-air playout computers. One machine acts as the central playout system. It can run nonstop automation and, depending on the station workflow, may also handle fixed broadcast elements such as news, commercials, promos or station imaging.

The live studios run their own Power Studio instances. The central playout machine can delegate the on-air state to one of those studio machines when a presenter, local program or live studio takes over. When the live studio is no longer active, the central system can continue the automated output.

This is a more advanced setup, but it can be very powerful for stations with:

  • multiple physical studios;
  • a separate automation or central playout room;
  • programs that move between studios;
  • a mix of nonstop automation, live shows, news and commercial blocks;
  • mixer or routing systems that can follow the active studio automatically.

Plan this setup carefully. Every studio computer needs a clear studio number, predictable audio routing, correct Multi Studio settings and a tested control path to the mixer or routing system. If the station uses mixer plugins, GPIO, LiveWire, Ember+, DHD Global Logics or MambaNet, decide which system is responsible for switching the active studio and test the complete chain before using it on air.

Depending on the studio hardware, the active studio can be switched or followed by systems such as Axia mixers, D&R AXUM/AXITE mixers, DHD mixers, Ember+ matrices or Sonifex Redbox RB-(D)SS10 audio switchers. In those installations, document which device performs the actual audio switching, which Power Studio instance controls it and what should happen when control is lost.

Use a dedicated database and shared audio storage for this type of installation. Also plan a fallback procedure: operators should know what happens if the central playout machine, a studio playout machine or the network connection between them becomes unavailable.

See Multi Studio settings and Multi-Studio Coordination.

Dedicated Database And File Server

For larger stations, use a dedicated database server and a dedicated file server or high-quality NAS. The on-air machine then focuses on playout while other workstations use the same central database and audio paths.

This setup is the most flexible and resilient. It is also the most demanding: networking, permissions, backups and monitoring must be configured carefully.

For stations with several simultaneous workstations, a Windows Server system or a professionally managed file server is usually a better choice than using a normal Windows desktop computer as a server. A desktop Windows machine can work in small setups, but it is not designed to be a busy shared file server for many clients.

Plan server hardware as broadcast infrastructure, not as a normal office PC. More memory, a reliable SSD, proper cooling, good power protection and server-grade components are often more valuable than the highest possible CPU clock speed.

Hardware Planning

Treat minimum system requirements as the starting point, not the target for an on-air installation.

For a production or on-air workstation, plan enough CPU and memory for:

  • live playout;
  • playlist editing;
  • database browsing;
  • waveform loading;
  • recording or voice tracking;
  • metadata output and control plugins;
  • virus scanner and Windows background activity.

For a computer that also runs PostgreSQL, add extra headroom. PostgreSQL, Power Studio and file sharing can all be active at the same time, especially during imports, backups, playlist generation and remote work.

For a dedicated server, prefer:

  • a modern supported Windows version;
  • fast SSD storage for the operating system and PostgreSQL data;
  • enough memory for the database and file cache;
  • reliable network hardware;
  • a UPS;
  • a backup destination that is not the same disk set as the live database and audio storage.

Avoid unsupported Windows versions for new installations. They may still appear to work, but driver support, security updates and future Power Studio updates become harder to guarantee.

Audio Path Planning

Power Studio stores the full audio file path in the database. Every Power Studio computer must be able to access audio files through the exact same path.

Good options are:

  • A fixed mapped drive letter, such as M:\Audio.
  • A UNC path, such as \\PowerStudioServer\Audio.

Do not let different computers use different paths for the same audio files. If one computer imports a file as D:\Music\song.wav and another computer expects M:\Music\song.wav, the second computer will not find it.

Choose the final audio root before importing a large library. Do not import from a temporary desktop folder, download folder or USB drive and then move the files later.

Plan a folder structure that editors can understand. Common examples are:

  • Music;
  • Jingles;
  • Promos;
  • Commercials;
  • VoiceTracks;
  • Recordings;
  • Syndicated;
  • Temporary.

Music can also be structured in a way that supports library work. For example, a station can divide music by category, format, decade, period, source, program or import batch:

  • Music\Current;
  • Music\Recurrent;
  • Music\Gold;
  • Music\1980s;
  • Music\1990s;
  • Music\1980s\Rock;
  • Music\1980s\Pop;
  • Music\Program Jingles;
  • Music\To Review.

This can make the first import easier. When a folder contains a clear group of tracks, use batch import to set shared properties and categories for that group quickly and consistently. For example, tracks imported from a Music\1980s folder can receive the correct decade, tracks imported from Music\1980s\Rock can receive both the correct decade and genre/category, tracks imported from Music\Current can receive the correct rotation or category, and program-specific material can receive the right content type or special category during import.

Do not make the folder structure more detailed than the station can maintain. Power Studio stores the real operational metadata in the database; folders are mainly there to keep storage understandable and to make import and maintenance work easier.

The exact structure is a station decision. The important point is that the structure is stable, shared and backed up. Avoid personal folders for audio that must be available on air.

Storage And Network Advice

Use fast internal disks, enterprise storage, or a well-performing file server. External USB drives are not recommended for broadcast audio storage.

For network playout, use gigabit or faster networking with reliable switches and network cards. Avoid low-end consumer NAS devices for live playout unless they are known to provide stable SMB performance under load.

Standard consumer NAS devices are often acceptable as backup targets, but they are not always suitable as live playout storage. The issue is not only raw transfer speed. Directory browsing, many small file lookups, SMB behavior, disk sleep settings and simultaneous users can all affect how quickly audio becomes available.

For larger installations, use an end-to-end gigabit or faster network:

  • gigabit or faster network cards in all relevant computers;
  • gigabit or faster switches throughout the path;
  • good cabling;
  • no hidden 100 Mbps switch between studio and server;
  • stable IP addressing or DNS names for servers and audio-over-IP devices.

If the station uses Audio over IP (AoIP), it can be a good idea to put that traffic on a dedicated VLAN or a physically separate network. This keeps time-sensitive audio traffic away from normal office traffic, file copies, backups and internet use. Use managed switches that are suitable for the chosen AoIP system and document the VLANs, switch ports, IP ranges and any routing that is needed for Power Studio, mixer drivers or control plugins to reach the audio devices.

If the station uses a file server, test it under realistic load. Browse the library, open playlists, preview audio, play multiple players, record a voice track and run a backup or import test. A setup that works with one test file may still feel slow with a real library and multiple users.

Database Planning

Power Studio uses PostgreSQL. Decide where PostgreSQL will run before installing the first workstation.

For a stand-alone system, PostgreSQL can run locally on the same computer as Power Studio. For a multi-computer station, use a central database server and let all Power Studio clients connect to that database.

Choose a clear database name and do not reuse it for another station or test environment. A wrong database name can make a workstation appear correctly configured while it is connected to the wrong library, formats and users. The Power Studio license is linked to a specific database, so database naming and database selection are part of the real installation, not just a technical detail.

Plan database access together with security:

  • use a strong PostgreSQL password;
  • restrict PostgreSQL to the studio network, approved workstations or VPN addresses;
  • do not expose PostgreSQL directly to the public internet unless it is a deliberate, documented exception;
  • document the database server name, port, database name and application login;
  • keep administrator credentials separate from daily application credentials where the installation supports it.

See PostgreSQL Database Server for the detailed PostgreSQL setup.

Audio Hardware Planning

Plan audio hardware before the installation day. The on-air computer needs reliable audio outputs for the way the studio is operated.

At minimum, decide:

  • how many Playout Players will be used;
  • whether Player A-D need separate mixer faders;
  • whether Automation Mode uses its own output or shares a player channel;
  • where PFL and preview audio will go;
  • how cart players are routed;
  • which input is used for voice tracking and recording;
  • whether the station uses audio-over-IP, mixer drivers or GPIO/control plugins.

Onboard audio can be useful for testing or simple production work, but it is not a good target for a serious on-air chain. Use professional audio interfaces, broadcast mixer drivers or supported audio-over-IP drivers for the studio.

For 24/7 on-air computers, professional internal or IP-based sound devices are usually more stable than USB audio interfaces.

Install and test audio drivers before configuring Power Studio routes. Check that Windows exposes the expected devices and channel pairs. Driver updates can change device names or channel layouts, so document the chosen driver version and routing.

See Audio Routing and Audio Routing settings for the routing workflow.

VPN Planning

If presenters, producers, administrators or support engineers need access from outside the studio, plan VPN access as part of the installation. Remote access is useful for voice tracking, playlist preparation, library maintenance, database maintenance and support, but it should be limited to the resources that are actually needed.

A VPN is not a replacement for database and file-server security. PostgreSQL, Windows Firewall and Windows file sharing should still allow only the intended users, devices and network addresses.

For many Power Studio installations, Tailscale is a practical VPN option. A simple and clear design is:

  • install Tailscale on the database server;
  • install Tailscale on the file server if audio is stored on a separate machine;
  • install Tailscale on remote Power Studio workstations that need database or audio access;
  • allow PostgreSQL and file sharing only from the approved Tailscale devices or users;
  • keep the normal LAN restrictions in place for studio workstations.

This direct-client setup is clear and practical for Power Studio remote workflows. The database server and file server become normal Tailscale machines with their own stable Tailscale addresses, and access can be documented per machine.

Tailscale can also share specific machines with external users through machine sharing. This can be useful for a presenter, DJ or support engineer who should reach only the database server, file server or another specific station machine. The external user does not need a user account in the station's tailnet, but they do need to accept the share with their own Tailscale identity. Prefer sharing individual machines over giving broad network access, and revoke shares when they are no longer needed.

Before relying on remote work, document:

  • who owns and administers the VPN or Tailscale tailnet;
  • which station machines are reachable through the VPN;
  • which remote users and devices are allowed;
  • which PostgreSQL, Windows Firewall and file-sharing rules depend on VPN addresses;
  • how temporary access is removed after a guest, support or remote-production period.

Remote, Home And Location Work

If presenters, producers or administrators need to work from home or another location, plan that workflow separately from the normal studio installation.

Choose the remote workflow before installing the workstation. The two common approaches are Power Sync or direct studio access over VPN with Local Asset Cache.

With Power Sync, the required audio is duplicated locally on the remote machine. This is usually the most predictable workflow for remote voice tracking, because playback and recording do not depend on opening every audio file directly from the studio network during the session. It is especially useful on slower or less predictable internet connections. Start synchronization early enough, especially the first time. The initial synchronization can take a long time because Power Sync may need to copy a large part of the library, or all audio files in the selected sync scope, before the workstation is ready for real production work.

In a future version, the Local Asset Cache is expected to support connecting directly to a Power Sync server. Treat that as an upcoming option until the installed Power Studio version explicitly supports it.

With a VPN workflow, the remote workstation connects to the studio database and uses the studio audio storage through the expected shared path. Do not treat this as if it were simply another computer on a fast LAN. VPN latency, home internet speed and audio availability matter. In this setup, the Local Asset Cache can improve reliability by caching the audio Power Studio needs just in time as playlist items are opened, previewed or prepared for playout. Operators normally do not have to choose individual files to cache in advance.

For remote voice tracking or maintenance, decide and test:

  • whether the workstation uses Power Sync or VPN access with Local Asset Cache;
  • if Power Sync is used, whether the initial synchronization has completed and enough time is planned for future changes to synchronize;
  • if VPN is used, whether the workstation connects to the correct PostgreSQL database;
  • if VPN is used, whether the expected shared audio path is available remotely;
  • if VPN is used, whether Local Asset Cache should be enabled to improve reliability;
  • if Local Asset Cache is used, whether its full-playlist download or cache-only options are really needed for the user's work;
  • whether opening playlists, previewing tracks, recording voice tracks and saving changes works before using the setup for a real broadcast day.

For outside broadcasts or temporary locations, prepare the setup early. If the location uses Power Sync or a copied location set, start the synchronization or copy process in time and make sure the required audio is present before leaving the studio. The first Power Sync run can take much longer than later incremental updates. If the location uses VPN with Local Asset Cache, test the VPN connection, database connection, shared audio path, audio routing and any required plugins or control surfaces. The cache will decide which audio is needed as Power Studio opens and prepares the playlist. Full-playlist download and Play only cached files are Local Asset Cache options; they do not control Power Sync. Use them only when they have been deliberately tested for the broadcast.

See Power Sync Remote Workflow, Location Set and Local Asset Cache.

Backup Planning

Plan backups before the first production import. The database and the audio files are both required for a usable restore.

Back up:

  • the PostgreSQL database;
  • the complete audio storage;
  • exported configuration notes, plugin mappings and workstation roles;
  • any scripts used for backups, imports or scheduled tasks.

A 24/7 on-air computer is not used like an office computer. Disks, fans and power supplies are under continuous load. Do not wait for a failure before designing the backup workflow.

Use a backup destination that is not the live audio disk. A second internal disk can be useful for quick recovery, but it is not enough by itself. Keep at least one backup outside the studio or in another protected location.

RAID can improve availability, but RAID is not a backup. It does not protect against accidental deletion, database corruption, theft, ransomware or a failed import that overwrites good data.

Test restores periodically. A backup is only useful when the station knows how to restore it to a separate database or replacement machine.

See Database Backup for the Power Studio PostgreSQL backup workflow.

Security And Maintenance Planning

Before the system goes on air, decide who is responsible for maintenance.

Plan:

  • Windows Update windows;
  • PostgreSQL updates;
  • Power Studio updates;
  • audio driver updates;
  • antivirus or endpoint security policy;
  • firewall rules;
  • database backups and restore tests;
  • UPS and power recovery behavior.

Do not let maintenance software surprise the on-air machine during a live show. Antivirus and endpoint protection should protect the computer, but real-time scanning of large audio folders, database folders or backup jobs can cause extra load. Coordinate any exclusions with the station's IT policy and document them.

For most Power Studio installations, Microsoft Defender Antivirus, also known as Windows Defender on many systems, is usually sufficient. We have good experience with its relatively low impact on audio performance when the workstation is otherwise configured sensibly. Be more careful with third-party antivirus or endpoint suites: some of them perform heavier background scanning, web filtering, file inspection or update tasks, and that can affect disk, network or audio performance on an on-air computer.

See Windows Maintenance.

Migration From An Existing System

If the station already uses another automation system, plan the migration before importing files.

Prepare:

  • the final audio folder structure;
  • the content types that will be used in Power Studio;
  • category and scheduler criteria;
  • artist/title repeat rules;
  • user permissions;
  • playlist and format planning strategy;
  • commercial, promo and syndicated-program workflows;
  • a test database for trial imports where possible.

Do not judge the migration only by whether the files import. Check whether the imported metadata supports daily use: search, scheduling, Now Playing, reports, commercials, jingles, voice tracks and live playout.

Suggested Installation Order

Use this order as a practical starting point:

  1. Decide the workstation roles and choose the installation topology.
  2. Prepare Windows, drivers, network names and IP addresses.
  3. Prepare audio storage and choose the final shared audio path.
  4. Install and secure PostgreSQL.
  5. Create or restore the Power Studio database.
  6. Configure Power Studio on the first workstation with the Configuration Tool.
  7. Configure audio routing and test every player, cart, PFL path and recording input.
  8. Configure categories, content types, scheduler settings and basic station behavior.
  9. Import a small test set of audio and verify metadata.
  10. Configure backups before importing the full library.
  11. Import or migrate the full library.
  12. Configure plugins and external integrations one at a time.
  13. Add production, remote and training workstations.
  14. Run the First Run Checklist before live use.

Planning Checklist

Before installation, write down:

  • which computer is the on-air machine;
  • where PostgreSQL runs;
  • where the audio files live;
  • the exact audio path used by all workstations;
  • the database name;
  • the PostgreSQL server name and port;
  • which computers may connect to PostgreSQL;
  • which audio interface and driver version are used;
  • the player, cart, PFL and recording routing plan;
  • which workstations may run scheduled jobs or macros;
  • the backup destination and restore procedure;
  • the Power Sync synchronization plan or VPN with Local Asset Cache remote-work strategy;
  • who is allowed to change configuration settings.

This document does not need to be complicated. A short technical sheet with the final decisions is enough to prevent many installation mistakes later.