What Is Sparx EA Pro Cloud Server and Why Do You Need It?

The problem PCS solves

Plenty of teams start out with a local file repository — historically the .eap file, more recently the SQLite-based .qea format. A single file works fine for one architect working in isolation. It falls apart for a team: shared file access produces locking conflicts, corruption risk, and no real audit trail.

The enterprise answer is a shared database repository on SQL Server, PostgreSQL, or MySQL. But pointing Sparx EA clients straight at that database creates a fresh set of problems. Every architect needs direct database credentials. Connections cross network boundaries with no HTTPS in front of them. There is no central place to manage authentication. And browser-based access for non-modeling stakeholders is simply impossible.

Pro Cloud Server closes all of those gaps. It provides a managed access layer that handles:

• Connection brokering from Sparx EA clients to the database
• Authentication and access control, including integration with organizational identity providers
• HTTP/HTTPS gateway access for secure remote connectivity
• Model streaming for efficient access to large repositories
• Web access so stakeholders can view content without a full Sparx EA licence
• Audit logging of repository access and changes

In short, PCS turns a raw database into a professionally managed enterprise repository service.

How the pieces fit together

The clearest way to understand PCS is to see where it sits. Clients never touch the database directly; every connection is brokered through PCS, which also fronts a browser interface for read-only stakeholders.

What PCS does: the core functions

Connection brokering

PCS manages every connection from Sparx EA clients to the underlying database. Clients connect to PCS, and PCS manages the database connection pool on their behalf. The practical payoff: database credentials live in one place — the PCS configuration — instead of being scattered across client machines.

Authentication and security

PCS supports several authentication modes: Windows Authentication via Active Directory, PCS native user accounts, and, in enterprise configurations, SAML/SSO. Access to individual repositories can be controlled at the user or group level. That gives practice leads granular control over who reaches which repository, in which mode (read-only or read-write), and from where.

HTTP/HTTPS gateway

PCS exposes the repository over HTTP/HTTPS, letting clients connect across network boundaries without a VPN once HTTPS is in place. This matters for distributed teams, remote architects, and cloud-hosted repositories. Without PCS, every client needs direct network access to the database server — a heavy infrastructure and security constraint.

Model streaming

For large repositories, PCS streams model elements on demand rather than shipping the whole repository to the client. This is what keeps big Pro Cloud Server–hosted repositories usable over connections that would otherwise be too slow for a full transfer.

Web access (WebEA)

PCS includes WebEA, a browser-based interface for Sparx EA repositories. WebEA lets stakeholders without a full Sparx EA licence view diagrams, read element documentation, and navigate the model hierarchy. Where business stakeholders need to review architecture but will never open the modeling client, WebEA earns its place quickly.

PCS deployment options

PCS licensing

PCS is licensed separately from Sparx EA client licences. It comes in several editions — a free entry tier alongside paid Token, Team Server, and Enterprise editions — and the paid tiers govern how many web users and integration connections you can run, with tokens or model counts as the unit of scale.

A Sparx EA client licence lets a user connect to a PCS-managed repository; it does not grant the right to operate a PCS server. To deploy PCS you need both client licences (for the architects) and the appropriate PCS server licence (for the installation itself).

Sparx Services does not sell licences. As part of a Configure the Solution engagement, we calculate the exact licence bill of materials your deployment needs and hand it over as a recommendation. Your organization purchases directly from Sparx Systems.

Common PCS configuration mistakes

Using HTTP instead of HTTPS. Plain HTTP works, but it is wrong for production — credentials and model data travel in clear text. HTTPS needs a certificate (self-signed or CA-issued) and the matching configuration in PCS. Quick setups skip it; production setups cannot.

Leaving default ports exposed. PCS defaults to specific ports that should be reviewed against your network security policy. Default ports reachable on public interfaces without authentication controls are a real exposure.

Skipping authentication setup. PCS ships with user management for a reason. New installations left on default credentials or minimal access control are a security risk. Authentication should be configured — and tested — before any architect touches the production repository.

Misaligning PCS and client versions. The Sparx EA client and PCS need compatible versions; mismatches cause connection failures and odd behaviour. Upgrade them together.

Not testing remote access first. A configuration that works locally can still fail remotely thanks to firewall rules, certificate trust, or DNS. Test access from outside the server's own network before you call the deployment done.

What Sparx Services configures in Configure the Solution

A Configure the Solution engagement covers PCS end to end:

• PCS installation on your chosen infrastructure — on-premises or cloud VM
• Database driver setup and connection configuration
• HTTPS configuration with certificate handling
• Authentication setup (Windows Authentication or PCS native users, with AD integration where needed)
• Security policy configuration and access controls
• Repository creation and connection verification
• WebEA setup where stakeholder access is required
• Architect-team onboarding on PCS administration and connection management

By the end, PCS is not a draft. It is a production-grade, security-appropriate middleware layer ready to carry a live EA practice. It also leaves the repository well positioned for whatever connectivity layers you add later — reporting, business intelligence, or stakeholder portals — without architectural rework.

Frequently asked questions