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

For an architect, PCS is the part of the platform that decides who can reach the model, from where, and in what mode. By hand, access is granted one database account at a time. AI-augmented work puts more demand on the repository: more people and tools reading and changing the model, so the access design has to be right. The architect decides who should see and change what, and the administrators implement it in PCS. The free AI Power Tools for Sparx EA run on the same Windows machine as the EA client, so they work through the repository the client has open. The person needs a repository they can reach and trust.

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. Pointing Sparx EA clients straight at that database works, and it brings its own 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 not possible.

Pro Cloud Server addresses 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 license

In short, PCS puts a managed service in front of the raw database.

How the pieces fit together

The clearest way to understand PCS is to see where it sits. In a PCS deployment, clients connect through PCS instead of to the database directly, and PCS 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, including Windows Authentication via Active Directory and PCS native user accounts, with single sign-on options in newer versions. Check Sparx Systems' current documentation for what your version supports. 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, which is 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 keeps large 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 license view diagrams, read element documentation, and browse the model hierarchy. Where business stakeholders need to review architecture but will never open the modeling client, WebEA gives them a way in.

PCS deployment options

PCS licensing

PCS is licensed separately from Sparx EA client licenses. Its editions and limits change over time, so see Sparx Systems’ current pricing and edition details.

A Sparx EA client license 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 licenses for the architects and the appropriate PCS server license for the installation itself.

Sparx Services does not sell licenses. We can work out the license bill of materials your deployment needs and hand it over as a recommendation, and your organization purchases directly from Sparx Systems. The licensing guide walks through the pieces.

Common PCS configuration mistakes

Using HTTP instead of HTTPS. Plain HTTP works, but it is wrong for production because 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 an 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 behavior. 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 a sound PCS setup covers

A production PCS setup covers installation on your chosen infrastructure, database driver and connection configuration, HTTPS with certificate handling, authentication (Windows Authentication or PCS native users, with Active Directory where needed), security policy and access controls, repository creation and connection verification, and WebEA where stakeholders need access. The team that will administer it also needs to know how PCS administration and connection management work.

We can teach your architects and administrators to run this on your own infrastructure and mentor them until it sticks, or set up the environment and build the model for you and hand it over. A repository set up this way is ready for the reporting, business intelligence, or stakeholder portals you add later.

Frequently asked questions