Skip to content

CRM UK — Twenty CRM

Twenty CRM instance for the UK sales operation at crm.eidos-global.com. ~2 users today, used at leadership level to track pipeline. One of three sibling Twenty CRM instances on E2 Dokploy (UK / IN / TnE).

Field Value
Public URL https://crm.eidos-global.com
Audience UK leadership / sales (~2 users)
Criticality medium — strategically important pipeline data, low daily-usage volume
Maturity hobby/trial
Owner [INFO NEEDED]
Last reviewed 2026-05-07

1. At a glance

Self-hosted Twenty CRM running on Dokploy on E2. The UK leadership team uses it to track the sales pipeline and account list. Usage is minimal day-to-day today — about 2 users — but the strategic opportunity is real, hence we are running our own deployment rather than paying per-seat for a SaaS CRM.

Twenty is a modern open-source CRM (twenty.com) — comparable to HubSpot/Salesforce in shape, but we own the hosting and the data.

2. Business purpose

  • Pipeline visibility for UK sales / leadership.
  • Account + contact register.
  • Ground truth as the team scales — early days now, expected to grow.

3. Audience

UK leadership + UK sales. ~2 users today.

4. Hosting & cloud infrastructure

  • Server: E2 EIDOSDev1 Dokploy VPS (145.241.230.130)
  • Deploy method: Dokploy
  • Reverse proxy: Caddy on E1 → Dokploy/Traefik on E2 → Twenty container
  • Container topology: separate Twenty instance per CRM (3 distinct containers + 3 distinct Postgres DBs on E2) — multi-workspace mode wasn't available when these were set up; consolidation is a future option.

Infrastructure map

Item Value Notes
Public hostname crm.eidos-global.com DNS via E1 Caddy → E2
Backend host E2 (Dokploy) shared with 8 other apps
Twenty CRM image tag :latest not pinned — risk of breaking on next image update; same lesson as KI-033 but Watchtower is not on E2 so updates don't auto-pull. Still: consider pinning.
Database dedicated PostgreSQL container per CRM 3 separate Postgres instances on E2
File uploads / attachments local disk on E2 not in MinIO; lost if E2 dies
TLS cert Caddy auto-LE

Credentials in Vault

Secret type Vault location
Twenty workspace admin [INFO NEEDED]
Postgres password [INFO NEEDED]
App secret / signing key [INFO NEEDED]
SMTP credentials kv_pe/OCI-SMTP — shared across the entire estate (all APEX apps + all 3 CRMs use the same Oracle Email Delivery credential)

Architectural note — shared SMTP: all email-sending services (the 3 CRMs, the 5 APEX apps including Parallax and the TnE Connect tenants) use Oracle Email Delivery with one shared credential at kv_pe/OCI-SMTP. Sender addresses are admin@projecteidos.com and no-reply@projecteidos.com. Convenient and cost-effective; rotation has wide blast radius and any compromise is system-wide. Worth documenting as a deliberate design choice.

5. Technology behind it

  • Type: off-the-shelf
  • Product: Twenty CRM (open-source, twentyhq/twenty)
  • Stack: TypeScript / Node.js + PostgreSQL; containerized
  • Image tag: :latest (not pinned)

6. Data it handles

  • Customer / prospect contact details (PII — small volume)
  • Pipeline / deal information (commercial sensitivity)
  • Communication history
  • Few records today (early stage), expected to grow

GDPR posture: none formally. Two UK users today processing UK contact data — within scope when the volume scales but currently below the threshold for active concern. Worth a basic privacy-statement / consent-flow review before significant pipeline data accumulates.

7. External dependencies

  • E2 host availability
  • Oracle Email Delivery (shared SMTP, see above)
  • [INFO NEEDED] — any integrations not wired today (per Vishnu: none)

8. Authentication & access

  • End-user login: email-based magic link — Twenty's local accounts with no password; sign-in flow sends a one-time login URL to the user's email. Implication: the user's email account is the auth factor.
  • Workspace admin: [INFO NEEDED]
  • MFA: not applicable in the magic-link model — strength of auth is determined by the email account's MFA. M365 (corporate) MFA effectively becomes the CRM's MFA. Document this dependency.

9. Maturity assessment

Dimension Status Evidence
Backups Trial Dokploy-configured: both volume + DB are part of Dokploy's automatic backup. Never restore-tested, no documented procedure (KI-016).
Restore tested Hobby Not tested.
Monitoring Hobby None beyond OCI built-in.
Alerting Hobby None.
Redundancy Hobby Single container on a single host (E2).
Patching Hobby :latest tag but no Watchtower on E2 → image actually stays static; no security updates either. (KI-004)
Deploy process Trial Dokploy auto-deploy from container registry.
Auth Trial Email-magic-link delegates strength to M365 MFA.
Secrets handling Trial SMTP creds in Vault, application secrets [INFO NEEDED].

Overall: trial — fine for current low-volume usage, but the backup-untested and uploaded-files-on-local-disk gaps will matter as soon as the CRM holds anything load-bearing.

10. Known risks & vulnerabilities

  • Backup untested (KI-016) — Dokploy says it's backing things up; we have not proven we can restore.
  • File uploads on local disk on E2 — if E2 dies, every attachment is lost regardless of DB backup state. Should be backed by MinIO or copied to an OCI bucket on schedule.
  • Image on :latest — combined with no auto-update on E2, this means the image is stuck wherever it landed; no security patches either.
  • Three separate Twenty deployments instead of multi-workspace — three Postgres processes on E2, three sets of upgrades to manage. Future consolidation candidate.
  • No formal GDPR / privacy review — fine while volumes are tiny; revisit before scaling.
  • Magic-link auth means email-account compromise == CRM compromise — corporate M365 MFA is effectively the CRM's only MFA.
  • Shared SMTP credential — the OCI-SMTP Vault entry is reused across the entire estate. Convenient; rotation requires coordinated update.

11. Impact if it goes down

  • 2 UK users blocked from pipeline view.
  • Low immediate impact; small annoyance vs. real outage.
  • A data-loss event is a different story — pipeline data is hard to reconstruct.

12. Owner & on-call

[INFO NEEDED]

13. References & links