AI bundling: what drives the 46% increase
Since late 2024, major SaaS vendors have adopted a shared strategy: embedding AI features into every subscription tier and passing GPU compute costs onto all users, regardless of whether they use those features.
PricePulse data for H1 2026 illustrates the scale. Atlassian leads at +153%, driven by the forced migration of Server and Data Center licences to Jira Cloud, where Atlassian Intelligence is enabled by default. Notion is up 88% after rebranding as 'Notion AI' and repositioning AI as a standard plan component — there is no longer a plan without it. Asana rose 127% across its Business and Enterprise tiers, now centred on AI Studio and automated workflows. HubSpot (+50%) introduced Breeze, its AI engine, across nearly all its hubs.
The underlying mechanism is identical in each case. The vendor first breaks AI into seemingly optional features: summaries, suggestions, automations. It then makes them progressively unavailable on lower tiers, forcing upgrades. Finally, it removes the option to purchase a plan without AI, making the surcharge structural and permanent. For a 50-person team running several tools, the monthly bill can exceed what a self-hosted equivalent stack would have cost for an entire year.
What self-hosting changes for your team
- Cost control — you pay for the VPS, not a per-seat licence that rises with every vendor roadmap update.
- No forced bundling — you decide which features run on your infrastructure, including whether to integrate a local AI model or not.
- Data stays in your perimeter — simplified GDPR compliance: no additional sub-processor to declare for each tool, no DPA renegotiation at every pricing renewal.
- Budget predictability — a properly sized VPS costs the same in January and December, regardless of the vendor's pricing strategy next year.
- Version freedom — you freeze the version that fits your workflows and upgrade when you are ready, not when the vendor drops support for the old one.
- No dependency on vendor survival — an acquisition, pivot or shutdown does not put your data at risk: it stays on your server.
SaaS 2026 vs open source: what changes
| SaaS tool | H1 2026 increase | OSS equivalent | Min RAM |
|---|---|---|---|
| Jira | +153% | Plane | 2 GB |
| Notion | +88% | AppFlowy | 1 GB |
| Slack | ~+35% | Mattermost | 2 GB |
| HubSpot CRM | +50% | Odoo (CRM) | 4 GB |
Which tools self-host well
Not every tool self-hosts with the same level of maturity. Here is a category overview.
Team messaging. Mattermost is the reference: deployable with a single binary or via Docker, it supports webhooks, CI/CD integrations and video calls via a plugin. Element (Matrix) is a more decentralised alternative suited to teams spread across multiple legal entities.
Project management. Plane offers a Jira-like interface with sprints, issues and roadmaps. It deploys via Docker Compose and provides a documented API. GitLab (Community Edition) also covers project tracking if your team is already on Git. Forgejo, a Gitea fork, is a lightweight option for code-centric teams.
File storage and document collaboration. Nextcloud remains the most complete solution: file sharing, collaborative editing via Collabora or OnlyOffice, calendar, contacts and video conferencing. It runs on 2 GB RAM in minimal configuration, 4 GB for active teams.
Analytics. Plausible and Umami self-host easily and transmit no data to third parties. Metabase suits internal BI on your own databases.
CRM. Odoo Community covers sales, contacts and invoicing. It is more resource-intensive (4 GB minimum) but remains the most complete functional equivalent to HubSpot for structured sales teams.
Before migrating: three questions to answer
Three questions structure the decision before you start.
Are your data critical and exportable? Check that the current SaaS tool offers a complete export — CSV, JSON or API — and that the format is readable by the open-source equivalent you are targeting. Some vendors restrict exports to higher tiers or impose a delay. Test the export before committing to the migration, not during it.
Is the migration reversible? Define a rollback point: how long will you keep the SaaS subscription running in parallel with the self-hosted instance? Two to four weeks allows time to catch overlooked use cases (integrations, notifications, mobile access) without being caught off guard. An irreversible migration done under pressure is the main cause of failure.
Does your team have the skills to maintain it? Self-hosting transfers responsibility for security updates, backups and monitoring to your infrastructure. If no team member can handle these tasks, you need to train someone, delegate to a provider or reconsider the decision. This is not a deal-breaker, but it is a real cost to factor into the comparison.
Migrating in 6 steps
Inventory your current tools
List every active SaaS tool, the number of seats, the monthly cost and actual usage. A tool paid for 50 users but used by 10 is a priority candidate for migration or cancellation.
Choose the open-source equivalent
For each retained tool, identify the most mature OSS alternative and compare the essential features (not the full list, but actual daily use cases). Check the import documentation to verify compatibility with the SaaS export format.
Deploy a test instance on a dedicated VPS
Set up the tool on a test VPS separate from the future production environment. Verify performance under realistic load, configure HTTPS with a valid certificate and test essential integrations (email, webhooks, SSO if applicable).
Export and clean your SaaS data
Trigger the export from the current SaaS tool, verify the integrity of the file and clean the data if needed (duplicates, archived contacts, tickets closed more than a year ago). Importing clean data avoids reproducing accumulated clutter.
Import and validate in a staging environment
Import the data onto the test instance and validate with a subset of users: at least one representative per business use case. Document any functional gaps and decide whether each one is a blocker or acceptable.
DNS cutover and team communication
Point the tool's subdomain to the production VPS, communicate the cutover date to users with a quick-start guide. Keep the SaaS accessible in read-only mode for two to four weeks before cancelling the subscription.
Back up your SaaS data before cancelling the subscription, not just before the migration. Vendors delete cancelled accounts quickly — sometimes within 30 days — and the export is no longer accessible afterwards. Always test the full migration on a separate staging VPS before touching the production environment: an import that fails halfway through an empty database is recoverable; the same error on production may not be.
What self-hosting does not do for you
Migrating to self-hosting reduces the SaaS bill but transfers responsibilities that the vendor previously handled.
Security updates. A SaaS patched within 72 hours of a critical CVE publication is a promise the vendor delivers. On your VPS, your update procedure determines your exposure window. You need a routine for tracking security advisories for deployed tools and a tested update procedure, not just a documented one.
Monitoring and alerts. A Mattermost instance that has been silent for three hours because a Docker container crashed does not announce itself. You need external supervision (HTTP check, absence-of-response alert) separate from the server itself, and a notification configured for off-hours incidents.
User training. Plane's interface is not Jira's; AppFlowy's is not Notion's. The technical migration can be perfect and adoption can still fail without proper onboarding. Plan at minimum a quick-start guide and a hands-on session for users less comfortable with new tools.
Three common obstacles and how to overcome them
Three obstacles come up consistently in early migrations.
SSL configuration. Getting a valid certificate for a subdomain hosted on a VPS is straightforward with Let's Encrypt and Certbot, but automatic renewal is often overlooked. Configure auto-renewal from the first deployment, verify that it runs (cron or systemd timer) and manually test the renewal command before the certificate reaches its expiry date.
Performance under load. An undersized tool becomes slow as the team adopts it. The general rule: start with twice the minimum RAM indicated in the documentation, then observe real usage during the first two weeks. It is easier to resize a VPS than to justify a degraded experience to users.
Transactional email. Email notifications (password resets, assignment alerts, daily digests) require a configured SMTP server. Do not use your main domain's mail server for these sends: use a dedicated transactional email service that manages deliverability, bounces and domain reputation separately from your business email.
Which VPS to start with
Sizing depends on the number of tools deployed simultaneously and the team size.
For two tools (e.g. Mattermost + Plane) and fewer than 20 active users, a VPS with 4 GB RAM and 2 vCPUs is sufficient. Docker Compose lets you manage both services on the same machine with per-container resource limits, preventing one tool from monopolising all available memory during peak usage.
For five or more tools, or for teams of 20 to 50 people, a VPS with 8 GB RAM and 4 vCPUs provides a comfortable margin. Add a dedicated block volume for data storage (separate from the system disk): this simplifies backups and any future move to a more powerful server without having to migrate the operating system.
In both cases, Docker Compose remains a solid starting point: configuration files versioned in a Git repository serve as infrastructure documentation, and upgrading a tool reduces to changing the image tag and restarting the container.
