Skip to main content

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.

·OSSAlt Team
Share:

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

FunctionToolAlternative to
Project managementPlane or HulyAsana, ClickUp
CRMTwentyHubSpot
InvoicingInvoice NinjaFreshBooks, QuickBooks
Client communicationDocmost or OutlineBasecamp, Notion
Time trackingKimaiHarvest, Toggl
Design collaborationPenpotFigma
CMS for clientsDirectus or PayloadContentful, Webflow
CommunicationMattermostSlack
EmailListmonkMailchimp

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:

  1. Create a Company record for each client/prospect
  2. Add People (contacts) linked to each company
  3. Create Opportunities for new business discussions
  4. Convert won opportunities to active client records
  5. 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:

  1. Track time: Log hours per task in Invoice Ninja or Kimai
  2. Create invoice: Bill project-based or hourly at month end
  3. Send invoice: Client receives email with payment link
  4. Payment: Stripe or PayPal integration processes payment
  5. 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:

  1. Create a team per client
  2. Designers work in Penpot, clients review via share links
  3. Developers access inspect mode for CSS values
  4. 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.

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)

ToolMonthly
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

ComponentMonthly
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.

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.

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.

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.