[Feature]: Bootstrap all instance configurations from a helm chart

[joaocc]

Is there an existing issue for this?

• [X] I have searched the existing issues

Summary

We are trying to find a way to bootstrap a server from gitops workflow. A possible workflow would be to provide a helm deployment with a file-mounted YAML/JSON (from ConfigMap for instance) to configure all required initial configuration. This could include initial settings on credentials, data sources, organizations, apps, ...

Why should this be worked on?

For companies having a IAC/gitops hands-off workflow (and for those just wanting to automate testing and deployment), this would remove a blocker for automated testing and deployment, reducing errors and low-value added repetitive manual work. An interesting example of such a config on a complex system is keycloak, where init-files + keycloak-cli allow hands-off configuration.

[Lucienzera]

May I know whats the progress on this? Thanks!

[Nikhil-Nandagopal]

@Lucienzera we don't have this on our roadmap yet.

[Lucienzera]

@Nikhil-Nandagopal Is there a workaround that we can achieve this on our end? Just to sync up roles across all instances & environments

Thanks

[Nikhil-Nandagopal]

@Lucienzera yeah you could easily backup the mongodb from one instance and restore it in the new instance. That's the simplest way.

[Lucienzera]

@Nikhil-Nandagopal whats the definition of instance here? New application in a single workspace?

For context how we thinking to build our workflow is having multiple workspaces with different environment. And each of them might have more than a single application.

If im not mistaken the roles settings are tied to the workspace right?

Where can i do the mongodb backup and is it something that can overwrite in other instance?

Thanks

[Nikhil-Nandagopal]

@Lucienzera an instance is an installation of appsmith. All roles, apps, workspaces etc. will be transferred to the new instance. If you simply want to give users access to a set of apps or workspaces by default then you can achieve that using the rbac feature in the business edition.

[Lucienzera]

@Nikhil-Nandagopal Right, that's what we are doing currently. But we want to be able to share the rbac across other workspaces.

Instead of referring one another and ticking it one by one. Note that the apps are the same across different workspaces. Just varying data.

[jnikhila]

@Lucienzera To understand this better: you aim to configure access control settings on one Appsmith instance and then replicate these settings across multiple Appsmith installations. When you mention 'varying data,' are you referring to different installations using different datasources?

[Lucienzera]

@jnikhila Yes, multiple AppSmith workspaces which has multiple apps but are pointing to different environments of the same API. The apps behaves the same and look the same. But underlying data sets, example a customer table data might vary from workspace A then workspace B.

[jnikhila]

@Lucienzera - The backup and restore solution suggested by Nikhil will work. However, the staging APIs will have to be reconfigured post-restore as the data set is overridden. Will you be available for a quick call to understand the use case so I can suggest a solution?

[Lucienzera]

@jnikhila is there somewhere I can reach out to you privately maybe via email?

[jnikhila]

@Lucienzera - please use this link.

[Nikhil-Nandagopal]

Hey folks, instead of bootstrapping a config file would a better solution be to create official APIs that you can use to automate role creation & user management? The problem with a config file is that it can lead to merge conflicts in a git ops workflow where you are trying to promote a feature from staging to prod. We also have no way to properly detect conflicts because IDs across instances for the same object would be different.

[joaocc]

@Nikhil-Nandagopal are there any plans regarding this? Regarding your comment, having a CLI calling an API would also be OK, especially since a YAML (or json or ...) file could then be used to parameterise calls to the API. Even small things as configuring the initial settings and bootstrapping some git repos would help. Thanks

[Nikhil-Nandagopal]

@joaocc we're still planning this. Can you tell us why you would like to automate the import of repositories as well? We're right now primarily considering automating roles, user groups and user assignment.

[joaocc]

Well, repository setup usually requires several parameters to match (server, path, branch, user+credentials). Being able to automate it means we can link it to IAC/Devops/CI-CD remove another manual activity that adds no value. Thanks