We will be licensing our platform to multiple users who can run their own branded version of the platformn for their users. So the idea would be to duplicate the current platform, rebrand and redeploy on a new server with a blank fresh DB. However, this poses a problem. I would like to be able to update all “sub apps” from the Master App. So, in other words, lets say I have the “Master” app which I have updated or built new modules on, I would like to push the same update to all “Sub apps” preventing me from having to go and manually update all the sub apps with the same changes. If I have 100 sub apps this could be a huge problem. Also, would be good if each sub app had their own custom domain.
This would create “customer_1”, “customer_2”, etc. “projects”
A Bash script to re-deploy the docker-compose files would do the job, which would pull an updated container (Docker) image (which you’d have to create previously somehow). However, this doesn’t apply migrations (DB changes), because it’s missing this feature request (or similar):
In each project folder (in each customer folder) write a docker-compose.override.yml that adds the custom domain setting (e.g.: Traefik labels)
I know this post is a bit technical, but “complex” requests have “complex” solutions
If you need professional help, @ tbvgl is available for hire. Do note, regardless, Wappler is still lacking exposing DB migrations inside containers which is required for decent DB schema updates. This could be worked around by creating another Bash script that would rsync the migrations from your project to the remote server, and somehow apply them
Happy to help, David! In case you answered “yes” to the first question, I’d suggest to look into Microsoft Power Automate or other desktop automation tool (e.g.: UI.Vision RPA) to automate the deployment by using automatically clicking buttons on Wappler UI.
The goal would be to iterate through each server target (or similar) and perform the deployment as you would manually.
This approach requires thought to ensure it’s reliable, like checking if certain text exists on the screen before clicking a button. Imagine if a deployment fails, you don’t want to proceed with the script, so you need to explicitly check if it was successful before moving on
Hmm, so let’s take a step back. Let’s say I have 1 project open in Wappler (the “Master” App/project"), how do I add sub apps / duplicates of this project? I guess your answer above is helpful once I have the multiple projects open but how do I do it in one “project”?
You need to go to your project settings and add targets, each customer is one target. You could even deploy them on the same Docker server if you’re using the recent Docker implementation using Resource Manager (Cloud Servers only at the moment)
AAAh! okay so I create a new remote target for each client, and then once I am happy with the Master App and I am ready to deploy that to the live server, I just go and deploy the same to each target?
Fantastic! Thank you! So am I able to customise the look and feel of each remote target while working on that particular live version? I thought I had to work in development mode then deploy live?
Also, whats the difference between publish and deploy?
Okay so I need to specify color codes, logos etc in the DB for each client rather than having it read off the client side? So dynamic values instead of static? Also, if I decided to build an extra feature for 1 client, but not others, would this be possible with this setup?
Whats the difference between publish and deploy?
Also, I think I know the answer to this, but will each remote client have their own database that is isolated from each other?
Publish is deploy + run DB migrations (changes) in one-step
Yes, that should be the case
In the database, you can create a table to store configuration, and there you can have a column indicating if this instance is allowed to have feature xyz (e.g.: feature_contact_form: 1 [true])
Hi David.
We had recently built a white-labelling solution where a new DB instance and a new app server instance is created on Digital Ocean whenever a new client is onboarded.
We also built a custom extension which can generate bootstrap CSS file based on values provided by each client on their settings page, so that their instance is themed as required.
We built two apps - one is a UI for various custom stuff like create servers and running DB scripts etc.
And other was the main app, which has subscription based feature-restrictions etc.
Both are built on Wappler with custom extensions.
We use Caprover as the choice of app for managing deployments via Git. So anytime a new commit is done on Git, a webhook is sent to all client instances to pull latest code. For DB updates, a manual script has been written.
Apple has answered all your queries well I see. The purpose of writing this is to show that Wappler is open enough to support various custom actions so you can rely less on external apps for a solution like this… and there are different ways to approach this as well.
You mentioned that you built your solution whereby a new DB and server is created on digital ocean when onboarding - this is exactly what I am looking for. Was this done via a custom script or module that you wrote or did you use native Wappler UI? If native Wappler would you mind sharing how you did this?
Also, trying to figure out the best way to approach this based on Apples response. Right now in my “master app” i am creating new clients (which is just a new “Client” in the DB). Each client has its own config such as logo, primary color scheme, which features are available (I.e true or false) etc. My next step would be to to create a new remote target and publish the site to each target. However, now I am trying to figure out how each remote site can read the “master” site to determine their config settings. Any tips on this?
I checked with the developer, and we have not actually done this part yet. We have tested it out, just not created the functionality.
With that in mind, for server, we will be using DO APIs. So you can say its is native Wappler UI in a sense that we are just using the API steps in server actions.
For running DB scripts, custom extension will be created, which would use knex to run the DB script.
This would mean that you are using same DB for all clients.
I think you would need different DB server for all clients, when you setup the targets in Wappler, you can setup different DB credentials for each target/client as well.
I would recommend to setup two DBs. One DB where all client master information is. And other DB which holds application data. So whenever you create a new client, you will just have to create a new app DB instance, but not the main DB.
This main DB would also hold subscription and feature restrictions etc.
This would mean that your setup would have to refer the main DB frequently - to ensure subscription validity etc. - and then refer the client’s app DB instance for everything else.
One more thing to keep in mind:
If you use target based setup in Wappler, it would become difficult to manage client deployments once the list grows. Using Power Automate or UIPath etc robots will be required.
The benefit being you could use Wappler DB migrations to make changes in all client DB instances.
With the Git based Caprover setup that we have, we would not have to bother with creating a new target for each client.
But, we will have to manage DB changes manually (which can lead to human error), and execute them for each client’s DB instance via a custom extension (which is easy).
Small piece of advice: Multi tenant apps can be simple with a few tenants and become more complex when you scale. Maintaining and debugging issues with multiple databases for example might require a team at some point. Plan as much as you can ahead. For some apps it makes sense to use a single database for all tenants because then you only need to maintain one. If you do that then you will need to make sure to add a tenant id to every single table.
If your main concern is white-label versions for each tenant then I would go for a single database.
Thank you Tobias. The idea is to keep all “sub apps” the same as the “master” app (which is my local development version) along with same database table setup etc… just each tenant will have their own color scheme logo and certain features enabled. All I have done is created a new remote target for each tenant. So I would publish updates to each remote target which should all be the same. Do you think I might still encounter scaling issues for this setup?
Running on 1 db can be dangerous since all data is shared and 1 breach means a breach for all tenants.
Are you also suggesting I still spin up a new remote target for each tenant but they all connect to the same db?
