How to set up Nextcloud Talk with the High-performance backend for production meetings
The High-performance backend (HPB) is the set of services that takes over work Nextcloud Talk otherwise does inside its default setup, mainly signaling and media handling for calls with more participants. Teams implement it when meetings grow beyond small groups, when users join from networks that block direct connections, or when the organization needs recording or telephone dial-in. Before you install anything, check whether the default setup already covers your meetings. Write down the largest meeting you expect, how many meetings run at the same time and how many people join from outside the corporate network. Those three answers show whether the High-performance backend is a requirement now or an upgrade you can schedule later.
The module covers five parts, and each one needs a named owner. The signaling server coordinates participants and session setup. The media gateway forwards audio and video streams so that every participant does not have to send a separate stream to every other participant. TURN servers relay traffic for clients behind restrictive firewalls, so they must be reachable from outside your network on the ports and protocols the clients use. The recording backend captures sessions and needs its own storage and capacity planning. The enterprise SIP bridge connects meetings to telephone dial-in and falls within the Nextcloud Enterprise scope, so confirm its licensing before you design around it. Check the vendor documentation for which component versions match your Nextcloud Talk release, because the signaling server and Talk must stay compatible through upgrades.
The build starts with decisions, not installation. Choose where each service runs: on the same network segment as Nextcloud, in a DMZ, or in a separate cluster. Plan DNS names and TLS certificates for the signaling endpoint and the TURN servers, and decide who renews them. Define the shared secrets that connect Nextcloud to the signaling server, and set firewall rules for TURN and media traffic. For recording, decide whether storage sits on the same platform as your files and who may start, stop or download recordings. Sizing comes last and depends on your call volume data: peak concurrent participants, typical meeting length, the share of video calls, recording frequency and dial-in use. Collect that data from current meeting logs over a representative period. Do not size from total user count, because that number says little about peak load.
Verify the build against the failures that appear in production. Test a call from inside the network, from an external network and from a network that blocks direct peer connections, so that TURN is actually exercised. Run a multi-party call at your planned peak size and watch CPU, memory and bandwidth on each service. Test recording start, stop and download, and test SIP dial-in and dial-out if they are in scope. Plan for the common problems: an expired certificate, a closed TURN port after a firewall change and a version mismatch after a Nextcloud upgrade. Ask any implementation partner for a written test plan and acceptance criteria before work starts. The quote should list each component, who operates it and which costs recur, including infrastructure, bandwidth, storage and any enterprise subscription.
What Nextcloud Talk and its High-performance backend do
Nextcloud Talk covers everyday chat and calls, while the High-performance backend and its companion services handle the work that grows with call volume and network conditions. Each card below is a separate component that you can scope, size and test on its own. Confirm limits and supported client versions in the current Talk admin documentation before you set requirements.
Chat, calls and meetings
Talk gives users chat rooms, one-to-one and group calls, and scheduled meetings inside the same Nextcloud accounts that control file sharing. Where conversations are stored depends on your server and storage design, and room access follows the users and groups you already manage. Check which browser and mobile client versions your staff use, and confirm the supported versions in the current Talk admin documentation before you set a support baseline.
High-performance backend for larger calls
The High-performance backend is a separate service that handles signaling and media for calls once they grow beyond small groups. It runs alongside your Nextcloud server and needs its own hosts, network routing and TLS endpoints, so size it from expected concurrent participants and typical call length. Confirm participant limits, deployment options and component versions in the current Talk admin documentation before you fix the topology.
TURN relays for restricted networks
Some participants sit behind corporate firewalls, carrier-grade NAT or strict proxies that block direct peer connections. TURN servers relay media for these users so they can still join, and the relays become a traffic path that your firewall rules and bandwidth plan must allow. Decide whether relays run in your data center, a DMZ or a cloud network you control, and check the ports, certificates and credentials the current Talk admin documentation requires.
Recording backend for meetings
The recording backend captures meeting audio and video so that authorized people can review it later. Recordings are often personal data and confidential material, so decide who may start a recording, where files are kept, how long they are retained and who may download them. Confirm the recording format, storage requirements and supported deployment model in the current Talk admin documentation, and plan participant consent notices for your jurisdiction.
Enterprise SIP bridge for telephony
The enterprise SIP bridge connects Talk meetings to telephone dial-in through your SIP trunking or PBX, so people without the app can join by phone. It is an enterprise component, so confirm licensing before you include it in scope. It also adds dial-in numbers, PIN handling and call routing to your change plan. Ask your telecom team which trunk, codec and regional number requirements apply, and confirm supported SIP platforms in the current Talk admin documentation.
Which Talk architecture decisions shape the build
This table compares the decisions to settle before installing Talk with the High-performance backend, from where signaling runs to how dial-in reaches meetings. Read each row against your network zones and telephony needs, because each option adds paths, firewall rules, storage or provider questions. The main takeaway is that TURN, recording and SIP dial-in each bring their own infrastructure and vendor checks, so decide them in the written scope before work starts.
| Decision | Options and when each fits | What it depends on | What to confirm |
|---|---|---|---|
| Where the High-performance backend runs | Co-located with Nextcloud for a small pilot, or on separate hosts for independent scaling and maintenance windows | Network path between Nextcloud and the backend, shared secrets, load balancing and host sizing | Supported topologies and connection requirements in the Talk admin documentation |
| How clients reach signaling and media | Direct public endpoints, or a reverse proxy in front of the backend for TLS and access control | DNS names, certificates, WebSocket support on the proxy and inbound firewall rules | Required endpoints, protocols and ports listed by the Talk documentation for your version |
| TURN: self-hosted or default path | Self-hosted TURN when users sit behind restrictive firewalls or the network must stay in your control; default path for open networks | Inbound ports, public IP or NAT mapping, certificates and outbound rules for each network zone | Whether the default path is acceptable for your data policy, and which TURN server version is supported |
| Number of TURN nodes | A single node for a small, single-site user base; several nodes for separate sites, guest networks or higher relayed call volume | Concurrent relayed calls, network segments, bandwidth per node and failover expectations | Sizing guidance for relayed traffic, and a load test with representative call patterns before go-live |
| TURN placement by network | One TURN tier for the office network, or separate nodes for remote users, guests and partner networks | Routing between zones, which networks clients use to connect and any split-DNS setup | Which clients and networks the Talk documentation expects TURN to serve, and how credentials are issued |
| Recording enabled or disabled | Disabled when meetings need no archive; enabled when policy requires recorded meetings for a defined group | Recording backend capacity for encoding, access rules, retention schedule and user notice requirements | Supported output formats, resource needs and whether recordings are covered by your retention and legal hold process |
| Where recordings are stored | Local disk on the recording backend for a single-site pilot; shared or object storage when recordings must survive host loss | Storage capacity growth, backup scope, encryption at rest, permissions and whether recordings appear in user files | Storage paths the recording backend writes to, file ownership needs and how cleanup is scheduled |
| SIP bridge for dial-in | Not needed when all participants join through Nextcloud; required when external callers must join by phone number | Telephony provider, phone numbers, SIP trunk, codec support and firewall rules for SIP signaling and media | Whether the enterprise SIP bridge is available under your Nextcloud subscription, supported providers and the number provisioning steps |
How the High-performance backend splits signaling from media
The main design decision in a Talk deployment is that control traffic and media traffic take different paths, and each path needs its own sizing, monitoring and firewall plan. When a user starts or joins a call, the client first authenticates through Nextcloud, which establishes the user's session and identity. Call setup, participant state and room changes then pass through the High-performance backend, the signaling service that Nextcloud Talk is configured to use. The audio, video and screen-share streams do not travel through that service. They flow peer to peer where a direct path exists, or through a media gateway in group calls. When a direct path is blocked by a restrictive network, TURN servers relay the media instead. Before design starts, confirm with the current Talk documentation which media modes your call sizes require.
Splitting the traffic changes how you size the platform. Signaling load grows with the number of calls, the number of participants joining and leaving, and the frequency of state changes. Media load grows with the number of concurrent streams and their bitrate, and it is the component most likely to need the most network capacity. A backend sized only by total user count will misjudge both. Plan the media gateway and TURN tier from peak concurrent calls and expected participants per call, and ask the vendor and documentation for the scaling units and resource guidance for each component. Do not carry figures over from older guides or blog posts, because component versions and recommended units change between Talk releases.
Separating the paths also defines your failure domains. A problem in the signaling backend usually stops new calls and joins from starting, while a problem in a TURN node mainly affects the users who depend on that relay. A media gateway failure affects group calls, and the Nextcloud server outage affects authentication for everyone. Decide which of these components share hosts, load balancers, databases or certificates, because shared dependencies turn separate failures into one outage. Test the behavior in a staging environment: restart the signaling service during a test call, remove one TURN node from rotation and observe what clients do. Record the results so operators know what users will see during each failure.
The split also drives firewall design, because each path has its own endpoints, directions and protocols. Clients need HTTPS access to Nextcloud and the signaling endpoint, while media needs the ports and relay ranges that the gateway and TURN servers listen on. Restrictive networks often require TURN over TCP or TLS on a port that web traffic can use, so decide whether TURN must be reachable from outside your corporate network, and from which address ranges. Ask your network team to map each flow by source, destination, protocol and port, using the exact values from the current Talk documentation. Plan DNS names and TLS certificates for each externally reachable service at the same time, since certificate errors are a common cause of failed joins.
Rollout sequence for a Talk deployment with the High-performance backend
This sequence takes a Talk deployment from version checks and network mapping through sizing, a tested build, call quality validation and optional recording and SIP bridge components, to a production cutover. Each step closes with an output the client keeps, such as a compatibility matrix, network diagram, sizing record, test report or runbook set.
Confirm Nextcloud and Talk version compatibility
Check the Nextcloud server version in place or planned, then confirm which Talk app release and High-performance backend release support it, along with the operating system, database and PHP versions the server requires. Upgrade-path rules apply, so if the server is behind, plan the one-major-at-a-time upgrade first. The output is a compatibility matrix that lists every component version and any change window a required upgrade needs. The step is done when the client's platform owner has approved every component version in writing.
Document network paths and firewall rules
Map every path a call uses: browser and mobile clients to Nextcloud, signaling traffic to the High-performance backend, media paths between participants, TURN relay for clients behind restrictive networks, and any outbound paths to recording or SIP systems. DeployOpen works with the client's network team to record ports, protocols, source and destination zones, DNS names and certificate ownership. The output is a network diagram and a firewall rule register approved by the security team before any build starts. The step closes when every flow has an owner and an approved rule.
Define call volume and concurrency with the client
Agree the figures the design must carry: expected peak concurrent calls, participants per call, the share of video versus audio calls, screen sharing use, and the meeting hours that create the peak. Collect these from usage data, calendar records or pilot figures where they exist, and label any value that is an estimate. The output is a sizing record that sets server and media capacity, TURN relay headroom and the failover target. The step is done when the client signs the sizing record and each assumption has a named owner who will confirm it during testing.
Deploy signaling, media and TURN in a test environment
Build the High-performance backend signaling server, the media component and the TURN servers in a non-production environment that matches the planned network zones and certificates. Connect a test Nextcloud instance to the backend, configure TURN credentials and confirm that clients reach the relay from each restricted network segment in the diagram. Keep configuration in version control so the production build repeats it exactly. The output is a working test stack and a configuration record. The step is complete when a multi-party test call succeeds over each planned path.
Validate call quality across clients and networks
Run a structured test matrix covering desktop browsers, the Talk mobile apps and the client's standard devices, across the network conditions the sizing record assumes. Include restricted networks that force TURN relay. Load tests use the agreed concurrency and participant counts and measure call setup, audio and video quality, and behavior when a node or TURN server fails. Each test case is logged with its result. The output is a test report with a pass or fail for every case and a list of tuning changes. The step closes when the agreed load runs without open failures.
Add recording and the SIP bridge if in scope
If the client has chosen call recording or the enterprise SIP bridge, deploy these components only after the core stack passes testing, so faults can be isolated. Recording needs storage location, retention and access decisions made with the data owner. The SIP bridge needs trunk details, a dial plan and the telephony team's sign-off on call routing. Each addition is tested again with the matrix from the previous step. The output is an updated network diagram, storage and retention settings, and test results for recording playback and inbound and outbound SIP calls. Where these features are out of scope, the plan records this step as skipped.
Run the production cutover and hand over runbooks
Schedule the cutover in a change window agreed with the client. Move production DNS names, certificates and firewall rules to the tested configuration, then confirm the first live calls from each client type. Write and rehearse the rollback steps before the window opens. After cutover, DeployOpen hands over runbooks covering start and stop order, scaling, TURN credential rotation, certificate renewal, monitoring thresholds, incident response and the upgrade procedure. The step ends when the client's operations team completes a handover walkthrough and accepts the runbook set.
What drives Talk implementation effort and cost
This table lists the drivers that change effort and cost in a Talk build, with what raises each one, what lowers it and what to request in a written quote. Read each row before you ask for a quote, because one driver can change the design of TURN, recording or SIP work. Sizing, duration and fee figures come from the written scope, not from this page.
| Driver | What increases it | What reduces it | What to request in a written quote |
|---|---|---|---|
| Concurrent participants and calls | Large all-hands meetings, many simultaneous calls, video on by default, screen sharing for large groups | Agreed peak concurrency, audio-first meetings for large groups, participant limits set in policy | Peak concurrent calls, participants per call, video share, and the sizing basis for the signaling server and media gateway |
| Networks and firewall zones TURN must cross | Several network segments, guest or branch networks, egress through a filtering proxy, strict outbound rules | Fewer zones on the media path, a documented egress policy, TURN placed close to where users connect | Inventory of zones and egress rules, TURN endpoints and ports, certificate handling, and test sites for each zone |
| Recording retention and storage | Recording of all meetings, long retention periods, large video files, storage in several locations | Opt-in recording, short retention for routine meetings, storage tiers that match your records policy | Retention by meeting type, storage location and encryption, deletion procedure, recording backups, and capacity growth assumptions |
| SIP trunk integration and dial-in numbers | More carriers, more dial-in numbers and regions, complex call routing, emergency call handling requirements | One carrier and a small set of numbers, routing kept in one place, a documented number map | Carrier and trunk details, number count and regions, dial-in plan, carrier test scope, and who approves number changes |
| Identity and user provisioning | Several directories, guest access without accounts, group-based room rules, more than one Nextcloud instance | One authoritative user source, a clear guest policy, reuse of existing directory groups | Directory source and attributes used, provisioning method, guest and moderator rules, and login tests for each user type |
| Load and quality testing | Many test scenarios, a wide range of client devices, mixed network conditions, repeated runs after tuning | Agreed test profiles, reusable test scripts, testing against the sized peak only | Test scenarios and pass criteria, client matrix, network impairment cases, retest scope after changes, and report format |
| Operations after go-live | Extended support coverage, many media nodes, frequent upgrades, recording and SIP changes, wider monitoring | Runbooks for common faults, monitoring of TURN and media health, upgrades scheduled in advance | Support hours, response expectations, who patches and upgrades, monitoring scope, handover terms, and which items are one-time or recurring |
How Talk connects to the rest of the Nextcloud platform
Nextcloud Talk with the High-performance backend depends on several platform services at once: the Nextcloud server, directory and sign-in systems, the reverse proxy, storage and telephony. Each connection needs an owner on your side, and most of the planning risk sits in the places where these systems meet.
Nextcloud server users and groups
Talk inherits its participants, conversation permissions and group visibility from the Nextcloud server accounts and groups. Decide early which groups may create conversations, which may join calls and whether guests are allowed. Confirm that the server version you run supports the Talk release and High-performance backend you plan to deploy, and check the supported database and PHP versions in the Nextcloud 35 system requirements before you fix the design.
LDAP or Active Directory accounts
If your people sign in with directory accounts, Nextcloud's LDAP app makes those users appear on the server, so Talk sees the same identities. Confirm which attributes and groups your directory exposes, how disabled or departed accounts are removed, and whether group membership used for Talk access is maintained in the directory rather than by hand on the server.
OpenID Connect or SAML sign-in
Browser sign-in for Talk runs through the Nextcloud login, so the identity provider choice affects every call join. Nextcloud documents OpenID Connect and SAML user authentication backends. Confirm with your identity team which protocol you will use, how sessions expire, and how multi-factor sign-in behaves for guests and external participants who join from outside your organization.
Reverse proxy and TLS certificates
Signaling, media and TURN traffic all depend on the reverse proxy and certificates in front of Nextcloud. Plan the hostnames, certificate issuance and renewal, and the paths that carry WebSocket traffic. Confirm with your network team which ports and protocols are open between clients, the signaling server, the media gateway and TURN servers, because a misrouted connection often looks like a failed call rather than a configuration error.
File sharing into calls
Talk lets participants share files from Nextcloud storage during a conversation, and those files keep the sharing and permission rules of the underlying file. Confirm which storage backend holds the files, how quotas apply to shared content and whether external shares are allowed. Users who cannot open a shared file will often report it as a Talk fault, so test the access path with real accounts.
Recording storage path
Recordings made with the recording backend are written to a location your team must choose and protect. Decide where recordings live, who may access them, how long they are retained and how they are backed up. Confirm the storage path and its capacity with your operations team before the first scheduled meeting, since recording volume depends on call length and participant count rather than on user numbers alone.
SIP telephony providers
The enterprise SIP bridge lets callers dial in from telephone networks. Your carrier or PBX must be able to reach the bridge, and the dial-in numbers, authentication and call routing need to be set up with that provider. Confirm the provider's supported codecs, number assignment process and emergency calling limits in writing, because these depend on the telephony contract rather than on Nextcloud.
Monitoring and alerting
Signaling, media, TURN and recording services each need health checks and logs that your monitoring stack can read. Decide which signals indicate a degraded call, such as rising join failures or TURN allocation errors, and who receives the alerts. Confirm that your existing monitoring tools can collect metrics from every component before go-live, so that the first call quality issue is not the first time the team sees any data.
How Nextcloud Enterprise support tiers affect a production Talk service
The support tier you buy determines who answers when a Talk meeting fails, how long a Nextcloud major version stays patched, and whether a clustered Nextcloud instance is covered. The community version receives monthly maintenance releases for each major version for one year, so a Talk service on community support must be upgraded on that cadence. Nextcloud GmbH sells Nextcloud Enterprise alongside the community edition for enterprise, public sector and education users. It is sold in Standard, Premium and a top tier, and the minimum purchase is 100 users. Before a Talk design is finalized, the platform owner should decide which tier fits the meeting load and the response expectations of the business.
The Nextcloud pricing page lists per-user, per-year prices starting at 71.29 euros for Standard, 104.99 euros for Premium and 204.75 euros for the top tier, for 100 or more users, with lower rates from 200 users. According to the same page, Standard includes one year of maintenance. Premium adds a maintenance lifecycle of five or more years, extended support hours and support for clustered instances. The top tier adds support up to 24/7 with response times down to one hour. These are the pricing page's own descriptions and can change, so ask Nextcloud GmbH or a reseller to confirm the current terms in writing before comparing tiers against your own service levels.
These terms matter more for Talk than for file sync because a failed call is visible at once. Talk depends on the Nextcloud server together with the High-performance backend signaling server, the media gateway and TURN servers, and an issue in any of them can stop a board meeting or a clinical consultation. Support hours determine whether a fault at night reaches an engineer quickly. Response time sets how long the business waits for a fix. Lifecycle length determines how many major upgrades you must perform, because Nextcloud does not allow skipping major releases. A longer lifecycle lets you schedule those upgrades, test Talk and its backends, and then roll them out in a planned window.
Before you buy, confirm which Talk components your meetings require and which tier covers each of them. Ask whether the High-performance backend, the recording backend and the enterprise SIP bridge are included in a tier, or whether each needs its own subscription, and whether a SIP bridge or recording backend is sold separately. Ask whether support covers the signaling and media components that DeployOpen installs in your infrastructure, or only the Nextcloud server. Request a written quote that states the tier, the user count, the per-user price, the term and each add-on by name. That quote is the basis for comparing Enterprise support against your own team's coverage.
Questions teams ask before hiring help for Talk
What drives the cost of a Nextcloud Talk deployment?
Scope and call pattern drive most of the cost. The main components are the High-performance backend (signaling server and media gateway), TURN servers for users on restricted networks, the recording backend, and the enterprise SIP bridge if you connect telephony. Each component adds design, configuration, testing and handover effort. Peak concurrent participants, the number of sites, whether recordings are kept, and how many firewalls the traffic must cross all move effort up or down.
One-time costs cover design, build, testing and knowledge transfer. Recurring costs cover hosting, upgrades, monitoring and any support retainer. Ask for a quote that separates these items, states who performs each task, and lists what is excluded, so you can compare it with your own team's estimate.
How long does a Nextcloud Talk build take?
The timeline is set in the written scope that both parties agree before work starts. This page does not give a duration. The main drivers are how many components are in scope, how many networks and firewalls the media traffic must cross, and how complete your network diagrams and identity details are at kickoff.
Testing also takes time. Call quality, failover and restricted-network paths each need verification cycles in your environment. Changes made during the build, such as a new recording retention rule or a second telephony trunk, move the schedule. Teams that prepare their inputs early usually wait less for answers. Ask for milestones that name the verification step for each component, so progress is tracked against agreed deliverables.
What must we provide before a Talk engagement starts?
Most delays trace back to missing inputs, so prepare these before kickoff. The core list is:
- Call volume: expected peak concurrent participants, meeting sizes and the share of video versus audio calls.
- Network diagrams: sites, firewalls, NAT, egress paths and any proxies between users and the servers.
- Identity source: the LDAP or Active Directory setup, or the OpenID Connect or SAML details, plus group mapping. Nextcloud documents LDAP and both protocols as user authentication backends.
- Telephony details: SIP trunk provider, dial plans, number ranges and supported codecs, if the SIP bridge is in scope.
- Storage for recordings: capacity, retention period, location and access rules.
You also need access to the cloud accounts, data centers or air-gapped network where the system will run, plus named contacts and change windows.
Can our in-house team deploy Nextcloud Talk without outside help?
Yes, if your team already runs Nextcloud and has the networking skills this design needs. The work spans Linux server administration, reverse proxy and TLS configuration, TURN and media networking, identity integration and load testing. The hardest part is usually not the installation but proving that calls work from every network your users actually use, including guest Wi-Fi, mobile networks and VPNs.
If your team has not run a media gateway or TURN relay before, plan for a learning period and check whether the same people will also run upgrades and incident response. Use a written test plan with call scenarios per network type. Outside help is most useful for the design decisions, the load test and the handover, but your team can do all of it with enough time and skills.
What happens after a Talk deployment goes live?
Operations work continues after go-live, and it recurs. Nextcloud publishes a new major version every four months and supports each one for a year through monthly maintenance releases. Each major upgrade must go one version at a time, with a backup taken before every upgrade and third-party apps disabled until they are confirmed compatible. Talk components also need monitoring, certificate renewal and capacity review as call volume grows.
Decide before go-live who owns each task, how alerts are handled and how recordings are reviewed or deleted under your retention rule. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Any response times or service levels must appear in the written agreement, so check them against your own incident process.
Why do some Talk users fail to join calls from restricted networks?
Calls usually fail when the media path cannot be set up directly and no TURN relay is reachable on a port the network allows. Corporate firewalls, strict NAT and some mobile carriers block the direct routes that browsers try first. The TURN server then has to relay audio and video, and it must be reachable over the transports your firewall permits.
To check this, test from a network that blocks direct UDP, from a guest network, from a mobile connection and from a VPN. Confirm the TURN service is reachable at the expected address, that its TLS certificate is trusted by clients, and that relay traffic is not throttled or inspected in a way that breaks media. Record the result for each network type so you can see which paths are covered.
How do we size the High-performance backend for our call volume?
Size it from peak concurrent participants and meeting types, not from total user count. Headcount tells you little about load. What matters is how many people are in calls at the busiest moment, how many meetings run at once, and how much of that is video and screen sharing. Recording adds load on the backend and on storage, and every relay path adds media traffic.
If you have conferencing logs from an existing tool, use them to estimate the peak. Where you have no history, the design should state the assumption and the load test should confirm it. Ask the implementation partner to show the sizing inputs, the test scenarios and the measured results, and to explain which numbers came from your data and which came from the vendor documentation.
Does Nextcloud Talk recording need its own storage planning?
Yes. Recordings need capacity, a retention rule, access control and a backup decision set before go-live. Recording files grow with meeting length and the number of meetings recorded, so storage needs depend on your usage pattern rather than on the number of users. Retention determines how long files stay and how much space they consume over time.
Decide who can start and view recordings, how participants are notified, and whether recordings are backed up with the rest of your Nextcloud data. Nextcloud All-in-One documents Talk with recording as one of its bundled components, but a High-performance backend design with a separate recording backend needs its own sizing and testing. Confirm each of these items in the written scope.
How DeployOpen scopes and delivers a Talk implementation
DeployOpen plans and builds Nextcloud Talk with the High-performance backend inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written scope that sets out the signaling, media, TURN, recording and SIP components you need, sized to your expected call volume. Delivery, testing, documentation and handover follow that scope, and ongoing support is available as a retainer.
How we scope
- The written scope lists which Talk components are in: signaling server, media gateway, TURN, recording and SIP.
- Call volume, concurrent participants, network zones and user locations are collected before any sizing decisions are made.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Components are deployed in your infrastructure, with the High-performance backend, TURN and recording services configured per the design.
- TURN relays are configured for restricted networks, including firewall rules and the ports your network team approves.
- Integrations such as identity provider sign-in and the enterprise SIP bridge are built and tested against your own systems.
How we hand over
- Configuration, network diagrams, sizing assumptions and runbooks are documented for your own operations team.
- Test results cover call quality, TURN fallback paths, recording and SIP call flows, with the evidence kept in writing.
- Backup and restore steps for Talk data and configuration are documented and tested before handover.
How we support
- Upgrades follow Nextcloud's one-major-version-at-a-time rule, with a backup taken before every upgrade.
- Third-party apps are checked for compatibility and kept disabled until confirmed before each Nextcloud upgrade.
- Ongoing support, upgrades and continuous testing can be covered by a retainer after handover.
