Self-Hosted Project Management: Deploy Onplana on AWS, Azure, GCP, or Docker

Self-hosted project management exists for a specific reason. Most project management software puts your project data on a server you will never see, in a cloud region someone else chose, under a terms-of-service that most teams accepted without reading the data-processing addendum. For most organizations, that is a reasonable tradeoff: the vendor handles the infrastructure and the team focuses on the work.

For a specific set of organizations, it is not a reasonable tradeoff at all. Defense contractors with CUI handling requirements. EU healthcare providers under Article 9 GDPR restrictions. Financial institutions subject to MiFID II data-residency rules. Government agencies with FedRAMP mandates. These teams need their project data to live in infrastructure they control, in a region they specify, under access policies they audit.

That is the use case self-hosted project management solves, and it is the use case Onplana's self-hosted deployment was built for.

TL;DR Onplana ships as a Docker image that deploys to any container runtime: single Docker, Docker Compose, Kubernetes, or managed container services on AWS, Azure, or GCP. The self-hosted version runs the same codebase as the SaaS product; no features are withheld. The tradeoff is operational: you own the upgrade cycle, backups, monitoring, and incident response. If data residency or sovereignty is not a requirement, SaaS is almost always the simpler path.

Who Actually Needs Self-Hosted Project Management

Self-hosted PM software solves a specific problem. Before evaluating any deployment option, confirm that your organization actually has the problem it solves.

Data residency and sovereignty requirements. If your organization operates under regulations that specify where project data must reside, self-hosted is the path. GDPR Article 44 restricts transfers of EU personal data outside the EEA without adequate safeguards. FedRAMP authorization limits where US government data can live. Some defense contracts require data to stay within a specific network boundary. SaaS vendors can offer data-residency options (Onplana's SaaS tier lets enterprise customers specify their Azure region), but for the strictest requirements, controlling the infrastructure directly is the only path to full compliance documentation.

Air-gapped or restricted-network environments. Some organizations cannot allow project management tooling to make outbound calls to a SaaS provider at all. Intelligence agencies, defense programs, and some regulated manufacturing environments require tooling that operates entirely within a private network. Self-hosted Onplana can run in an air-gapped environment with local container registries and no external dependencies once the image is pulled.

On-premise data integration requirements. If your PMO data needs to flow into an on-premise data warehouse, an ERP system, or a business intelligence platform that cannot reach the public internet, self-hosted PM gives you a direct integration path without egress through a third-party API.

Specific contractual or audit requirements. Some enterprise contracts require the vendor to demonstrate that project data never transits systems outside the customer's control. This is easier to certify when the entire deployment runs on customer-owned infrastructure.

If none of these apply to your organization, SaaS is almost certainly the better path. The operational overhead of running self-hosted infrastructure is real, and trading it for compliance assurance you do not need is the wrong tradeoff.

Onplana's Four Deployment Paths

Onplana's self-hosted offering supports four deployment patterns, scaling from a single-server setup to enterprise container orchestration. The diagram below shows how each pattern maps to infrastructure complexity and team size.

Single Docker container. The simplest path: pull the Onplana image, set the environment variables for your database connection and object store, and start the container. Appropriate for evaluation, proof-of-concept, and small teams where a single server is acceptable. Not recommended for production at scale: no redundancy, upgrades require downtime.

Docker Compose. Onplana ships a Docker Compose file that spins up the application server, PostgreSQL, and a local-compatible object store in a coordinated stack. This is the right starting point for teams of 20 to 100 users who want a managed-enough setup without committing to Kubernetes. Upgrades are straightforward: pull the new image and restart the stack.

Kubernetes. For teams that need high availability, horizontal scaling, or integration with an existing Kubernetes cluster, Onplana ships a Helm chart. This is the right path for 100-plus user deployments and for organizations that already run their infrastructure on Kubernetes and want PM tooling to live in the same operational model.

Cloud-native managed containers. For organizations running on AWS, Azure, or GCP, Onplana deploys to managed container services: AWS ECS/EKS, Azure AKS, or GCP GKE. The advantage here is managed control-plane overhead: the cloud provider handles node scheduling and cluster health while you retain full data sovereignty within your cloud tenant and region.

All four paths use the same Docker image. The difference is the orchestration layer and the hosting model, not the application itself.

What Stays the Same as SaaS

The most important thing to understand about Onplana's self-hosted deployment: it is the same codebase as the SaaS product. No features are withheld from self-hosted customers.

Full AI capabilities, including BYO Azure OpenAI. The AI Project Kickstart feature (natural-language to tasks and timeline in seconds), the AI risk detection, and the AI status report writer all run in self-hosted mode. Enterprise self-hosted customers can bring their own Azure OpenAI endpoint, which routes all AI calls through their own Azure tenant with no data leaving their infrastructure.

Full .mpp and MSPDI import. The Microsoft Project file import engine, including dependency type fidelity and baseline preservation, is not a SaaS-only feature. Self-hosted deployments have full .mpp round-trip support, including all four dependency types (FS, SS, FF, SF) with lag/lead values.

The full governance pipeline. The 12-stage gate governance system, stage criteria, RACI per gate, and audit trail are available in all deployment modes.

The same update cadence. Onplana publishes new releases on a regular cadence. Self-hosted customers pull updated images through the same Docker registry used for SaaS deployment. There is no second-class release track for self-hosted.

For a detailed view of what Onplana's security posture looks like in each deployment mode, including encryption in transit, encryption at rest, and access control model, the security overview and the security and compliance post cover the full technical architecture.

The Operational Overhead You Actually Take On

Self-hosted deployment shifts operational responsibility from Onplana to your infrastructure team. This is the right tradeoff for organizations with strict data-residency requirements. It is the wrong tradeoff if data residency is not a hard requirement, because the operational overhead is real.

Upgrade management. Onplana releases updates regularly. In SaaS, you get those updates automatically. In self-hosted, someone on your team needs to pull the new image, run any database migration scripts, and validate the upgrade in a staging environment before promoting to production. Expect this to take one to three hours per release for a competent infrastructure engineer.

Backup and disaster recovery. Onplana does not manage backups for self-hosted deployments. You own the PostgreSQL backup schedule, the object store replication, and the recovery procedure. For production deployments, this means designing and testing a recovery runbook before you go live, not after the first incident.

Monitoring and alerting. SaaS customers benefit from Onplana's monitoring infrastructure. Self-hosted deployments need their own observability stack: container health checks, database performance monitoring, object store availability, and application-level error alerting. Connecting the Onplana container to your existing monitoring platform (Datadog, Prometheus/Grafana, AWS CloudWatch) is straightforward, but it is work your team owns.

Incident response. When something breaks in a SaaS deployment, you file a support ticket. When something breaks in a self-hosted deployment, your infrastructure team is the first responder. Onplana support can help diagnose application-level issues, but infrastructure-level incidents are yours to manage.

For a small deployment (Docker Compose, under 50 users), the realistic ongoing maintenance load is two to four hours per week. For a Kubernetes deployment at enterprise scale, plan for a dedicated infrastructure resource with part-time PM tooling responsibility.

Self-Hosted vs. SaaS: How to Decide

The decision is not about features; both tracks have the same feature set. It is about where operational responsibility should live and whether your compliance situation requires it.

Dimension	SaaS	Self-Hosted
Data location	Onplana's cloud (configurable region for Enterprise)	Your infrastructure, your region
Operational responsibility	Onplana manages everything	Your team manages infrastructure
Upgrade cycle	Automatic	Manual pull and validate
AI data routing	Through Onplana's cloud	Through your infrastructure (BYO Azure OpenAI)
Air-gap support	No	Yes
Setup time	Minutes	Hours to days depending on path
Ongoing maintenance	None	2-4 hrs/week (small) to part-time (enterprise)
Best for	Most teams	Data-residency requirements, air-gapped networks

The question to ask is specific: does your organization have a hard requirement that project data must reside on infrastructure you control? If yes, self-hosted is the right path. If the answer is "we'd prefer it" or "it seems more secure," the operational overhead of self-hosted is likely not worth the benefit, and Onplana's SaaS Enterprise tier with region selection addresses most of those concerns without the maintenance burden.

Getting Started with Onplana Self-Hosted

The entry path for self-hosted evaluation is the single Docker deployment. It requires a container runtime, a PostgreSQL instance, and an S3-compatible object store. The Onplana features page has the full infrastructure specifications.

For organizations evaluating Onplana as a Project Online migration target in a self-hosted configuration, the self-hosted deployment supports the same .mpp and MSPDI import as the SaaS version. You can validate data fidelity against your real Project Online exports before committing to the deployment model. The security and compliance overview is the right starting point for security review documentation.

If you have questions about compliance certification requirements, data-processing agreements, or the BYO Azure OpenAI configuration for your specific regulatory framework, the contact page is the fastest path to a technical conversation.

The self-hosted option exists for teams that need it. For teams that do not have a hard data-residency requirement, SaaS delivers the same capabilities with less operational burden. Start with the requirement, not the deployment architecture.

Microsoft Project Online™ is a trademark of Microsoft Corporation. Onplana is not affiliated with Microsoft.