LogoLogo
  • 👋Cal.com Handbook
  • The Company
    • ❓What is Cal.com?
    • 📈Mission, Vision and Values
    • 🅰️Glossary
    • 📈Organization Chart
  • HR & Careers
    • 👷Contract-to-hire trials
    • 🛫Onboarding
    • 🏆IC Levels
      • ⛰️Engineering Levels
        • 🕵️IC1 Engineer (Code Cadet)
        • 👷‍♀️IC2 Engineer (Code Craftsperson)
        • 🧘‍♀️IC3 Engineer (Code Connoisseur)
        • 🧙‍♂️IC4 Engineer (Code Wizard)
    • 💡Sharing your views
    • 💸Bonus & Equity Structure
  • Policies
    • 🏖️Vacations
    • 💳Expenses
    • 🗣️Communications
  • Engineering
    • 🔔Managing Notifications
    • ⭐Valuable Bookmarks
    • 🐛How to report issues
    • 💻How we work on Tickets
    • 🔥What to do during Emergencies
    • ✅PR Reviews
    • ☑️Self-reviews
    • 📚Keeping Docs up-to-date
    • 🌐HTTPS & Subdomains
    • 🎯Best practices
      • Data fetching
      • Avoid Prop Drilling
      • Prefer defaultHandler for simple API handlers
      • Prefer inferred types over explicit ones
      • Prefer early returns
      • Avoid comparing multiple values with `includes`
      • Validate using zod instead of type casting
      • Prefer Composition over Prop Drilling
      • Prefer ternaries over Short Circuiting “&&” for React Components
      • Don't modularize prematurely
      • Only select data you need
      • Disallowing the use of unrestricted Metadata fields
      • E2E Tests Best Practices
    • 💻Codebase
      • 🔓Keeping the lock file in sync
      • 🚫Git Private Submodules
      • 🏎️Monorepo / Turborepo
      • 🌝Deploying to Production
      • ☁️Deployment
      • 💻Debug Desktop App
      • 🚩Enabling/Disabling Features
    • 🔺Resolving failed migration on Vercel Preview
    • 🔦Cal.com Status Page
  • Customer Success
    • 💟Tone
  • Marketing
    • 🎬Media
    • ☝️How to add a new Tip to Sidebar
  • 🤲Sales
    • Operations Stack
Powered by GitBook
On this page
  • Why?
  • Website
  • Console
  • API

Was this helpful?

  1. Engineering
  2. Codebase

Git Private Submodules

As part of our monorepo, we have some private git submodules that are private.

Why?

Although we try to keep as much of our codebase as possible open source. We don't want to make it too easy for a wanna be competitor or copy-cat to just clone our repo and setup mycal.com to compete with us, thus, some more sensitive parts of our codebase or like our landing / marketing pages at cal.com will remain private closed source repos, which will live under git private submodules in our main monorepo.

Website

This is our main landing page when you go at cal.com, it contains our proprietary signup implementation, which let's you purchase a subscription for a -premium- username at cal.

It also contains our blogposts and other landing pages.

Console

The console is a private repo and not shared with anyone, console is where we control all the related stuff to deployments, keys, add-ons, etc. All kind of users will access it via console.cal.com to manage their subscriptions/deployments/keys for self-hosted enterprise instances.

Since we don't want any code related to console to leak into the public repos, it syncs with the user at website when you signup, but creates a new user in a separate console database that holds the customer data. This user data gets synced via cronjob once a day.

API

Although API is a private submodule and closed-source, self-hosted infra customers can get access to the code in order to run API alongside their self-hosted cal instance.

PreviousKeeping the lock file in syncNextMonorepo / Turborepo

Last updated 1 year ago

Was this helpful?

💻
🚫