2đź‘Ť
The general principle is to have multiple domains, or sub-paths, pointing to the same back-end code. E.g.
http://customer1.myapp.com/
http://customer2.myapp.com/
or
http://myapp.com/customer1/
http://myapp.com/customer2/
You then have your application code use the URL (hostname, path, etc) to make decisions about what content to show. One popular approach with PostgreSQL is to SET search_path to reflect the currently active customer and have clones of all the customer-specific tables. Personally, I think it’s rather cleaner to instead add a WHERE clause term that filters rows by customer; this avoids all the duplicate table definitions and the resulting hassle when making DDL changes, and it lets you partition tables in more flexible ways.
If you’re doing it with search_path you’ve got to watch out for application-level caches that might not understand that the customer_user table it’s looking at now isn’t the one it saw last request, for a different customer. This is another good reason to use WHERE clause based partitioning instead.
I suggest searching for information on “django multi-tenancy” or “django multi-tenant” for the Django-specific bits; I really do the database backend side and a bit of general application front-end work in a variety of tools (not currently including Django).