Open-source alternatives guide
Open Source Stack for Digital Agencies 2026
Open source stack for digital agencies in 2026. Replace $50-200/user/month SaaS tools with self-hosted project management, CRM, billing, and communication.
The Agency Software Problem
A typical digital agency uses:
- Project management: Asana or ClickUp ($10-24/user/month)
- CRM: HubSpot or Salesforce ($15-75/user/month)
- Invoicing: QuickBooks or FreshBooks ($15-55/month)
- Client portal: Basecamp or Notion ($6-15/user/month)
- CMS for clients: Webflow ($23-49/month per site)
- Team communication: Slack ($7-12/user/month)
For a 5-person agency serving 10 clients: $500-1,200+/month in software subscriptions.
This guide covers building a complete open source agency stack — from project management to client portals to invoicing — that runs for the cost of a server.
The Open Source Agency Stack
| Function | Tool | Alternative to |
|---|---|---|
| Project management | Plane or Huly | Asana, ClickUp |
| CRM | Twenty | HubSpot |
| Invoicing | Invoice Ninja | FreshBooks, QuickBooks |
| Client communication | Docmost or Outline | Basecamp, Notion |
| Time tracking | Kimai | Harvest, Toggl |
| Design collaboration | Penpot | Figma |
| CMS for clients | Directus or Payload | Contentful, Webflow |
| Communication | Mattermost | Slack |
| Listmonk | Mailchimp |
Core Components
Project Management: Plane
Plane (46K+ GitHub stars) is the most mature open source project management tool for agencies. It handles client projects, internal work, and team sprints with a clean interface that non-technical clients can navigate.
Agency-specific features:
- Multiple workspaces (keep client projects separated)
- Issues, cycles (sprints), and modules (epics/features)
- Custom states matching your agency workflow (Discovery, Design, Development, Review, Done)
- Time tracking per issue
- Git integration (link commits to issues)
Self-hosting Plane:
# Single command install
curl -fsSL https://raw.githubusercontent.com/makeplane/plane/master/deploy/selfhost/install.sh | bash
After setup, create a separate project per client engagement. Use labels for project phase and priority.
Plane for clients: Consider giving clients viewer access to their project. They can see progress without editing anything. This eliminates "where are we on X?" emails.
CRM: Twenty
Twenty (25K+ GitHub stars, MIT) is a modern open source CRM built to replace HubSpot and Salesforce for agencies and small businesses. Clean interface, good API, and actively developed.
Why Twenty for agencies:
- Client and contact management
- Deal pipeline for new business
- Activity tracking (calls, emails, meetings)
- Notes and documents per contact
- Integration with email (connects to Gmail/Outlook)
Self-hosting Twenty:
services:
twenty-server:
image: twentycrm/twenty:latest
ports:
- "3000:3000"
environment:
SERVER_URL: https://crm.yourdomain.com
POSTGRES_URL: postgresql://twenty:twenty@db:5432/twenty
REDIS_URL: redis://redis:6379
STORAGE_TYPE: local
APP_SECRET: ${APP_SECRET}
depends_on:
- db
- redis
restart: unless-stopped
db:
image: postgres:16-alpine
environment:
POSTGRES_DB: twenty
POSTGRES_USER: twenty
POSTGRES_PASSWORD: twenty
volumes:
- pg_data:/var/lib/postgresql/data
restart: unless-stopped
redis:
image: redis:7-alpine
restart: unless-stopped
Agency workflow with Twenty:
- Create a Company record for each client/prospect
- Add People (contacts) linked to each company
- Create Opportunities for new business discussions
- Convert won opportunities to active client records
- Log all communication history in the contact timeline
Invoicing and Time Tracking: Invoice Ninja
Invoice Ninja (8K+ GitHub stars) is the most complete open source invoicing solution for agencies. It covers the full billing lifecycle: time tracking → invoicing → payment collection.
What Invoice Ninja includes:
- Professional invoices with your branding
- Quotes/proposals (send before work starts)
- Expense tracking (record subcontractor costs, tools, etc.)
- Time tracking with task-level granularity
- Recurring invoices (retainer clients)
- Payment links (Stripe, PayPal)
- Client portal (clients see their invoice history)
- Multi-currency support
Self-hosting Invoice Ninja:
services:
app:
image: invoiceninja/invoiceninja:latest
environment:
APP_URL: https://billing.yourdomain.com
APP_KEY: ${APP_KEY}
DB_HOST: mysql
DB_DATABASE: ninja
DB_USERNAME: ninja
DB_PASSWORD: ${DB_PASS}
MAIL_HOST: ${SMTP_HOST}
MAIL_USERNAME: ${SMTP_USER}
MAIL_PASSWORD: ${SMTP_PASS}
volumes:
- ./public:/var/www/app/public
- ./storage:/var/www/app/storage
depends_on:
- mysql
restart: unless-stopped
mysql:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: ${DB_PASS}
MYSQL_DATABASE: ninja
MYSQL_USER: ninja
MYSQL_PASSWORD: ${DB_PASS}
volumes:
- mysql_data:/var/lib/mysql
restart: unless-stopped
Agency billing workflow:
- Track time: Log hours per task in Invoice Ninja or Kimai
- Create invoice: Bill project-based or hourly at month end
- Send invoice: Client receives email with payment link
- Payment: Stripe or PayPal integration processes payment
- Reconcile: Expense tracking shows margin per project
Pro tip: Use Invoice Ninja's quote feature before projects start. Clients approve the quote, which converts directly to a project record. When the project ends, convert to an invoice with one click.
Time Tracking: Kimai
Kimai (3K+ GitHub stars, MIT) is dedicated time tracking software — more granular than Invoice Ninja's time tracking when you need it.
When to use Kimai over Invoice Ninja time tracking:
- Multiple team members tracking time simultaneously
- Complex time sheet reporting by client/project/team member
- JIRA/project tool integration
Self-hosting Kimai:
docker run -d \
-p 8001:8001 \
-v kimai_var:/opt/kimai/var \
-e DATABASE_URL=mysql://kimai:kimai@mysql/kimai \
kimai/kimai:latest
Export Kimai time reports to CSV → import into Invoice Ninja for invoicing.
Client Documentation: Docmost
Docmost (19K+ GitHub stars) serves as your client-facing knowledge base and internal documentation system.
Agency uses for Docmost:
- Project briefs: Document client goals, target audience, brand guidelines
- Deliverable specs: Detailed specifications for each deliverable
- Meeting notes: Shareable meeting summaries for client sign-off
- Style guides: Maintain brand guidelines for ongoing clients
- SOPs: Internal processes your team follows
Client collaboration tip: Create a Space per client in Docmost. Invite the client's primary contact as a Viewer (or Editor for collaborative documents). Clients see their project documentation without seeing other clients' data.
Self-hosting Docmost:
services:
docmost:
image: docmost/docmost:latest
environment:
APP_URL: https://docs.yourdomain.com
APP_SECRET: ${SECRET}
DATABASE_URL: postgresql://docmost:${DB_PASS}@db:5432/docmost
REDIS_URL: redis://redis:6379
ports:
- "127.0.0.1:3000:3000"
depends_on:
- db
- redis
restart: unless-stopped
Design Collaboration: Penpot
Penpot (35K+ GitHub stars, MPL-2.0) is the open source Figma alternative. For agencies doing UI/UX design, Penpot provides collaborative vector design with developer handoff features.
What Penpot includes:
- Vector design editor (similar to Figma)
- Real-time collaboration
- Component libraries and design systems
- Prototype interactions and animations
- Developer handoff (inspect mode with CSS/measurements)
- Open design format (SVG-based, no vendor lock-in)
Self-hosting Penpot:
curl -L https://raw.githubusercontent.com/penpot/penpot/main/docker/images/docker-compose.yaml | docker compose -f - up -d
Agency workflow with Penpot:
- Create a team per client
- Designers work in Penpot, clients review via share links
- Developers access inspect mode for CSS values
- Export assets directly from Penpot
CMS for Client Websites: Directus
Directus (28K+ GitHub stars, BSL-1.1*) is a headless CMS that wraps any SQL database with a REST/GraphQL API and admin interface. It's excellent for giving clients an editing interface for their websites.
Directus for agency use:
- Deploy one Directus instance per client (or multi-tenant)
- Create a custom data model matching the client's content types
- Give clients an admin login with permission to edit their content only
- Developers build the front-end with any framework
- Client edits go to your Directus instance → shows on their site
Self-hosting Directus:
services:
directus:
image: directus/directus:latest
ports:
- "8055:8055"
environment:
SECRET: ${DIRECTUS_SECRET}
DB_CLIENT: pg
DB_HOST: db
DB_DATABASE: directus
DB_USER: directus
DB_PASSWORD: ${DB_PASS}
ADMIN_EMAIL: admin@yourdomain.com
ADMIN_PASSWORD: ${ADMIN_PASS}
depends_on:
- db
restart: unless-stopped
Note: Directus uses BSL (Business Source License) for v10+. Review license terms for your use case — it's permissive for most agency scenarios but has restrictions for competing commercial products.
Team Communication: Mattermost
Mattermost (30K+ GitHub stars) is the open source Slack alternative with Enterprise features available in the Community edition.
Self-hosting Mattermost:
services:
mattermost:
image: mattermost/mattermost-team-edition:latest
ports:
- "8065:8065"
volumes:
- mattermost_data:/mattermost/data
- mattermost_logs:/mattermost/logs
environment:
MM_SERVICESETTINGS_SITEURL: https://chat.yourdomain.com
MM_SQLSETTINGS_DATASOURCE: postgres://mattermost:${DB_PASS}@db/mattermost?sslmode=disable
depends_on:
- db
restart: unless-stopped
Mattermost's Community Edition includes channels, direct messaging, file sharing, and integrations — sufficient for agencies under 200 users.
Recommended Server Setup
A full agency stack on Hetzner CPX41 (16GB, 6 vCPUs, ~$19/month):
Services running:
- Plane (project management): 300MB RAM
- Twenty CRM: 500MB RAM
- Invoice Ninja: 400MB RAM
- Docmost: 400MB RAM
- Mattermost: 600MB RAM
- Penpot: 1GB RAM
- PostgreSQL: 500MB RAM
- Redis: 100MB RAM
- Caddy (HTTPS): 50MB RAM
---------------------
Total: ~4-5GB RAM used
Available for growth: 11GB
This leaves headroom for additional client-specific Directus instances or Immich for asset management.
Complete Docker Compose Stack
services:
# ── Project Management ──
plane-web:
image: makeplane/plane-frontend:latest
ports:
- "127.0.0.1:3001:3000"
restart: unless-stopped
# ── CRM ──
twenty:
image: twentycrm/twenty:latest
ports:
- "127.0.0.1:3002:3000"
environment:
SERVER_URL: https://crm.yourdomain.com
POSTGRES_URL: postgresql://twenty:${DB_PASS}@db/twenty
REDIS_URL: redis://redis:6379
restart: unless-stopped
# ── Invoicing ──
invoiceninja:
image: invoiceninja/invoiceninja:latest
ports:
- "127.0.0.1:3003:80"
environment:
APP_URL: https://billing.yourdomain.com
APP_KEY: ${NINJA_KEY}
DB_HOST: mysql
DB_DATABASE: ninja
DB_USERNAME: ninja
DB_PASSWORD: ${DB_PASS}
restart: unless-stopped
# ── Documentation ──
docmost:
image: docmost/docmost:latest
ports:
- "127.0.0.1:3004:3000"
environment:
APP_URL: https://docs.yourdomain.com
APP_SECRET: ${DOCMOST_SECRET}
DATABASE_URL: postgresql://docmost:${DB_PASS}@db/docmost
REDIS_URL: redis://redis:6379
restart: unless-stopped
# ── Team Chat ──
mattermost:
image: mattermost/mattermost-team-edition:latest
ports:
- "127.0.0.1:8065:8065"
environment:
MM_SERVICESETTINGS_SITEURL: https://chat.yourdomain.com
MM_SQLSETTINGS_DATASOURCE: postgres://mattermost:${DB_PASS}@db/mattermost
restart: unless-stopped
# ── Shared DB ──
db:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: ${DB_PASS}
volumes:
- pg_data:/var/lib/postgresql/data
restart: unless-stopped
redis:
image: redis:7-alpine
restart: unless-stopped
# ── MySQL (for Invoice Ninja) ──
mysql:
image: mysql:8
environment:
MYSQL_ROOT_PASSWORD: ${DB_PASS}
MYSQL_DATABASE: ninja
MYSQL_USER: ninja
MYSQL_PASSWORD: ${DB_PASS}
volumes:
- mysql_data:/var/lib/mysql
restart: unless-stopped
Cost Comparison
Commercial Agency Stack (5-Person Team)
| Tool | Monthly |
|---|---|
| ClickUp Business (5 users) | $60 |
| HubSpot Starter CRM | $15 |
| FreshBooks Plus | $55 |
| Basecamp (client docs) | $25 |
| Slack Pro (5 users) | $40 |
| Figma Professional (5 users) | $75 |
| Total | $270/month, $3,240/year |
Open Source Stack
| Component | Monthly |
|---|---|
| Hetzner CPX41 server | $19 |
| Domain (multiple subdomains) | $2 |
| Total | $21/month, $252/year |
Annual savings: $2,988. The open source stack provides equivalent or better functionality for 8% of the commercial cost.
Find More Tools for Your Agency
Browse all agency and business tools on OSSAlt — compare Plane, Twenty, Invoice Ninja, Penpot, Directus, and every other open source business tool with deployment guides and use case comparisons.
Operational Criteria That Matter More Than Feature Checklists
Most self-hosting decisions are framed as feature comparisons, but the better question is operational fit. Can the tool be upgraded without a maintenance window that panics the team? Is configuration stored as code or trapped in a UI? Are secrets rotated cleanly? Can one engineer explain the recovery process to another in twenty minutes? These are the properties that decide whether a self-hosted service remains in production or gets abandoned after the first incident. Fancy template libraries and long integration lists help at evaluation time, but the long-term win comes from boring traits: transparent backups, predictable networking, obvious logs, and a permission model that does not require guesswork.
That is also why platform articles benefit from linking horizontally across the stack. A deployment layer does not live alone. Coolify guide is relevant whenever the real goal is reducing friction for application deploys. Dokploy guide matters when multi-node Docker or simpler PaaS ergonomics drive the decision. Gitea guide becomes part of the same conversation because source control, CI triggers, and deployment permissions are tightly coupled in practice. Treating those services as a system instead of isolated products leads to much better architecture decisions.
A Practical Adoption Path for Teams Replacing SaaS
For teams moving from SaaS, the most reliable adoption path is phased substitution. Replace one expensive or strategically sensitive service first, document the real support burden for a month, and only then expand. This does two things. First, it keeps the migration politically survivable because there is always a rollback point. Second, it turns vague arguments about self-hosting into measured trade-offs around uptime, maintenance hours, vendor lock-in, and annual spend. A good article should push readers toward that discipline rather than implying that replacing ten SaaS products in a weekend is responsible.
Another overlooked issue is platform standardization. The more heterogeneous the stack, the more hidden cost accrues in upgrades, documentation, and debugging. When two tools solve adjacent problems, teams should prefer the one that matches their existing operational model unless the feature gap is material. That is why the best self-hosting guides talk about package boundaries, reverse proxy habits, backup patterns, and team runbooks. They are not just product recommendations. They are deployment strategy.
Related Reading
Operational Criteria That Matter More Than Feature Checklists
Most self-hosting decisions are framed as feature comparisons, but the better question is operational fit. Can the tool be upgraded without a maintenance window that panics the team? Is configuration stored as code or trapped in a UI? Are secrets rotated cleanly? Can one engineer explain the recovery process to another in twenty minutes? These are the properties that decide whether a self-hosted service remains in production or gets abandoned after the first incident. Fancy template libraries and long integration lists help at evaluation time, but the long-term win comes from boring traits: transparent backups, predictable networking, obvious logs, and a permission model that does not require guesswork.
That is also why platform articles benefit from linking horizontally across the stack. A deployment layer does not live alone. Coolify guide is relevant whenever the real goal is reducing friction for application deploys. Dokploy guide matters when multi-node Docker or simpler PaaS ergonomics drive the decision. Gitea guide becomes part of the same conversation because source control, CI triggers, and deployment permissions are tightly coupled in practice. Treating those services as a system instead of isolated products leads to much better architecture decisions.
A Practical Adoption Path for Teams Replacing SaaS
For teams moving from SaaS, the most reliable adoption path is phased substitution. Replace one expensive or strategically sensitive service first, document the real support burden for a month, and only then expand. This does two things. First, it keeps the migration politically survivable because there is always a rollback point. Second, it turns vague arguments about self-hosting into measured trade-offs around uptime, maintenance hours, vendor lock-in, and annual spend. A good article should push readers toward that discipline rather than implying that replacing ten SaaS products in a weekend is responsible.
Another overlooked issue is platform standardization. The more heterogeneous the stack, the more hidden cost accrues in upgrades, documentation, and debugging. When two tools solve adjacent problems, teams should prefer the one that matches their existing operational model unless the feature gap is material. That is why the best self-hosting guides talk about package boundaries, reverse proxy habits, backup patterns, and team runbooks. They are not just product recommendations. They are deployment strategy.
Related Reading
Operational Criteria That Matter More Than Feature Checklists
Most self-hosting decisions are framed as feature comparisons, but the better question is operational fit. Can the tool be upgraded without a maintenance window that panics the team? Is configuration stored as code or trapped in a UI? Are secrets rotated cleanly? Can one engineer explain the recovery process to another in twenty minutes? These are the properties that decide whether a self-hosted service remains in production or gets abandoned after the first incident. Fancy template libraries and long integration lists help at evaluation time, but the long-term win comes from boring traits: transparent backups, predictable networking, obvious logs, and a permission model that does not require guesswork.
That is also why platform articles benefit from linking horizontally across the stack. A deployment layer does not live alone. Coolify guide is relevant whenever the real goal is reducing friction for application deploys. Dokploy guide matters when multi-node Docker or simpler PaaS ergonomics drive the decision. Gitea guide becomes part of the same conversation because source control, CI triggers, and deployment permissions are tightly coupled in practice. Treating those services as a system instead of isolated products leads to much better architecture decisions.
A Practical Adoption Path for Teams Replacing SaaS
For teams moving from SaaS, the most reliable adoption path is phased substitution. Replace one expensive or strategically sensitive service first, document the real support burden for a month, and only then expand. This does two things. First, it keeps the migration politically survivable because there is always a rollback point. Second, it turns vague arguments about self-hosting into measured trade-offs around uptime, maintenance hours, vendor lock-in, and annual spend. A good article should push readers toward that discipline rather than implying that replacing ten SaaS products in a weekend is responsible.
Another overlooked issue is platform standardization. The more heterogeneous the stack, the more hidden cost accrues in upgrades, documentation, and debugging. When two tools solve adjacent problems, teams should prefer the one that matches their existing operational model unless the feature gap is material. That is why the best self-hosting guides talk about package boundaries, reverse proxy habits, backup patterns, and team runbooks. They are not just product recommendations. They are deployment strategy.
Related Reading
The SaaS-to-Self-Hosted Migration Guide (Free PDF)
Step-by-step: infrastructure setup, data migration, backups, and security for 15+ common SaaS replacements. Used by 300+ developers.
Join 300+ self-hosters. Unsubscribe in one click.