What Is Sparx EA Pro Cloud Server and Why Do You Need It?
Pro Cloud Server (PCS) is the middleware layer that sits between Sparx EA clients and the shared repository database. Without it, multi-user Sparx EA requires direct database access — impractical, insecure, and unmanageable in most enterprise environments. PCS handles connection brokering, authentication, security, HTTP/HTTPS gateway access, and model streaming. It is what makes Sparx EA viable for teams rather than individuals. PCS is a separate licensed product from Sparx Systems, runs on a Windows server (on-premise or cloud VM), and must be properly configured before multi-user EA practice can begin. If you are deploying Sparx EA for a team, PCS is not optional.
Key Takeaways
- PCS is the connection broker between Sparx EA clients and the repository database — it is required for multi-user deployment
- Without PCS, multi-user access requires direct database connectivity, which is impractical and insecure
- PCS provides HTTP/HTTPS access, authentication, security, and model streaming
- Deployment options include on-premise Windows server, cloud VM (Azure/AWS), and Sparx Cloud (SaaS)
- EA GraphLink sits alongside PCS — both serve different functions and are complementary, not interchangeable
- Sparx Services Deploy covers full PCS configuration, security hardening, and EA GraphLink readiness
The Problem PCS Solves
Early-stage Sparx EA users often start with an EAP file — the default single-file repository format. EAP files work fine for individual architects working in isolation. They do not work for teams. Sharing an EAP file across multiple architects produces conflicts, corruption, and no audit trail.
The enterprise solution is a shared database repository (SQL Server, PostgreSQL, or MySQL). But raw database access for Sparx EA clients creates its own problems: every architect needs direct database credentials, connections cross network boundaries without HTTPS, there is no authentication management layer, and web access is impossible.
Pro Cloud Server solves all of this. It provides a managed access layer that handles:
- Connection brokering from Sparx EA clients to the database
- Authentication and access control (including integration with organisational identity providers)
- HTTP/HTTPS gateway access, enabling secure remote connectivity
- Model streaming for efficient large-model access
- Web access for stakeholders who need to view repository content without a full Sparx EA licence
- Audit logging of repository access and changes
PCS effectively turns a raw database into a professionally managed enterprise repository service.
What PCS Does: The Core Functions
Connection Brokering
PCS manages all connections from Sparx EA clients to the underlying repository database. Clients do not connect to the database directly — they connect to PCS, which manages the database connection pool. This means database credentials are centralised in PCS configuration, not distributed across client machines.
Authentication and Security
PCS supports multiple authentication modes: Windows Authentication (Active Directory integration), PCS native user accounts, and — in enterprise configurations — SAML/SSO integration. Access to specific repositories can be controlled at the user or group level. This gives EA practice leads granular control over who can access which repositories, in what mode (read-only vs read-write), and from where.
HTTP/HTTPS Gateway
PCS exposes repository access over HTTP/HTTPS, enabling Sparx EA clients to connect across network boundaries without VPN (when HTTPS is configured). This is essential for distributed teams, remote architects, and cloud-hosted repositories. Without PCS, Sparx EA clients require direct network access to the database server — a significant infrastructure and security constraint.
Model Streaming
For large repositories, PCS provides model streaming — a mechanism that loads model elements on demand rather than transferring the entire repository to the client. This is what makes large-scale EA repositories usable over network connections that would otherwise be too slow for full-repository transfers.
Web Access
PCS includes WebEA — a browser-based read-only interface for Sparx EA repositories. WebEA allows stakeholders who do not have a full Sparx EA licence to access repository content, view diagrams, read element documentation, and navigate the model hierarchy. For organisations where business stakeholders need to review architecture without using the full EA client, WebEA is valuable.
PCS Deployment Options
On-Premise Windows Server
The most common deployment configuration. PCS runs on a Windows Server instance in your data centre or server room. The database (SQL Server, PostgreSQL, or MySQL) can run on the same server or a dedicated database server. This configuration gives you full control over the environment but requires you to manage patching, backups, and availability.
Best for: Organisations with existing Windows Server infrastructure, strong preference for on-premise hosting, or data residency requirements that preclude cloud hosting.
Cloud VM (Azure or AWS)
PCS runs on a Windows Server virtual machine hosted in Azure or AWS. The database runs on a managed cloud database service (Azure SQL, Amazon RDS, etc.). This configuration combines PCS flexibility with cloud infrastructure benefits — managed database, auto-scaling, geographic distribution.
Best for: Organisations with a cloud-first infrastructure strategy, distributed teams who need geographic proximity to repository infrastructure, or existing Azure/AWS environments.
Sparx Cloud (SaaS)
Sparx Systems offers a hosted Sparx Cloud service where PCS is managed by Sparx Systems. Organisations subscribe to repository hosting without managing any server infrastructure. Sparx Cloud handles PCS configuration, patching, availability, and backup.
Best for: Small to mid-size teams who want to avoid server management overhead, organisations in early stages of EA practice building, or practices where IT infrastructure ownership of an EA server is difficult to justify.
PCS and EA GraphLink: Different Roles
EA GraphLink is Sparx Services’ AI and BI connectivity layer for Sparx EA. It is a distinct product from PCS and serves a different function. Understanding the difference is important because they are sometimes confused.
PCS connects Sparx EA clients to the repository database. It handles multi-user access, authentication, and security. PCS makes the repository accessible to architects.
EA GraphLink connects the Sparx EA repository to AI systems (including MCP-compatible AI agents), BI tools, and external data consumers. It makes repository content queryable by external intelligence layers — enabling natural-language queries, AI-assisted architecture analysis, and BI dashboard integration. EA GraphLink requires a properly configured PCS deployment as its foundation, but its function is entirely additive.
When Sparx Services configures a Deploy engagement, we configure PCS for secure multi-user access and position the repository so that EA GraphLink can be added without architectural rework. This EA GraphLink readiness configuration is included in Deploy.
PCS Licensing
PCS is licensed separately from Sparx EA client licences. PCS licences are purchased from Sparx Systems and are based on the PCS edition (Floating, Token) and the number of concurrent connections or models hosted.
Sparx EA client licences allow users to connect to a PCS-managed repository — they do not include the right to operate a PCS server. If you are deploying PCS for your organisation, you need both EA client licences (for architects) and PCS server licences (for the PCS installation).
Sparx Services does not sell licences. As part of a Deploy engagement, we calculate the exact licence bill of materials your deployment requires and provide it as a recommendation. Your organisation purchases the licences directly from Sparx Systems.
Common PCS Configuration Mistakes
Using HTTP instead of HTTPS. HTTP configuration works but is inappropriate for production environments — credentials and model data are transmitted in clear text. HTTPS requires a certificate (self-signed or CA-issued) and certificate handling in PCS configuration. This step is often skipped in quick setups and must be remediated before the deployment is production-appropriate.
Default port exposure. PCS defaults to specific ports that should be reviewed against your network security policy. Default port configurations that are accessible on public network interfaces without authentication controls are a security risk.
Skipping authentication configuration. PCS includes user management. New PCS installations with default credentials or minimal access control are a security exposure. Authentication should be configured — and tested — before any architect is given access to the production repository.
Not aligning PCS and EA client versions. Sparx EA client and PCS must be on compatible versions. Misaligned versions cause connection failures and unexpected behaviour. During upgrades, PCS and EA clients should be upgraded together.
Not testing remote access before launch. PCS configuration often works for local connections but fails for remote access due to firewall rules, certificate trust issues, or DNS resolution problems. Testing remote access — from outside the server’s local network — should happen before the deployment is considered complete.
What Sparx Services Configures in Deploy
A Sparx Services Deploy engagement covers PCS configuration comprehensively:
- PCS installation on your chosen infrastructure (on-premise Windows or cloud VM)
- Database ODBC driver setup and connection configuration
- HTTPS configuration with certificate handling
- Authentication setup (Windows Authentication or PCS native users, with AD integration where required)
- Security policy configuration and access controls
- Repository creation and connection verification
- WebEA setup (if required for stakeholder access)
- EA GraphLink readiness configuration — so AI connectivity can be added without rework
- Architect team onboarding on PCS administration and connection management
By the end of Deploy, PCS is not a draft configuration. It is a production-grade, security-appropriate middleware layer ready for a live EA practice.
FAQ
Is Pro Cloud Server required if we only have one architect? If a single architect is working alone and never needs to share repository access, they can use an EAP file (the local file repository format) without PCS. But in practice, even small teams benefit from PCS — it enables backup, web access for stakeholders via WebEA, and the ability to add more architects without infrastructure reconfiguration. If there is any prospect of team growth or stakeholder access, PCS setup from the beginning is the right choice.
Can PCS run on Linux? No — Pro Cloud Server runs on Windows Server only. If your infrastructure is Linux-first, the recommended approach is a small Windows Server VM dedicated to PCS, with a Linux-hosted database (PostgreSQL) for the repository data. PCS and the database do not need to run on the same operating system.
What is the difference between PCS and WebEA? PCS is the middleware server that manages repository connections. WebEA is a browser-based read-only interface included with PCS that allows stakeholders to view repository content without a Sparx EA licence. WebEA is served by PCS — you configure WebEA within PCS settings. They are part of the same product, not separate products.
How many repositories can a single PCS instance support? A single PCS instance can support multiple repositories — there is no hard limit on repository count per PCS installation. Resource limits (CPU, RAM, concurrent connections) are the practical constraint. Enterprise deployments typically segment repositories by domain, programme, or security classification, all hosted through a single PCS instance.
What happens if the PCS server goes down? When PCS is unavailable, Sparx EA clients cannot connect to the shared repository — the multi-user access layer is offline. Architects who have recently worked on models may have content cached locally. Stakeholder access via WebEA is also unavailable. For this reason, production PCS deployments should have monitoring, alerting, and a defined restart procedure. High-availability PCS configurations (load-balanced, with failover) are possible but add infrastructure complexity.
Does Sparx Services manage PCS as part of Platform Support after Deploy? Yes. Sparx Services Platform Support covers PCS monitoring, patch management, configuration updates, and incident response. Platform Support is the ongoing service that follows a Deploy engagement — it ensures PCS remains production-grade as EA versions update, team sizes change, and configuration requirements evolve.
Ready to Deploy Sparx EA With a Production-Grade PCS Configuration?
Sparx Services Deploy configures Pro Cloud Server correctly from the start — HTTPS, authentication, security, EA GraphLink readiness — so your EA practice launches on solid infrastructure rather than a provisional setup.
