Wappler Resource Manager: Store provider configuration in separate JSON file

Feature Request
#1

Hello,

Concerning Wappler’s Resource Manager, please consider storing provider configuration in a separate JSON file instead of putting in .wappler/project.json

Provider configuration includes stuff like API keys which one might not want to put in a Git repository when working in a team.

Excerpt of JSON 
  "resources": {
    "providers": {
      "hetzner": {
        "provider-api-key": "_CONFIDENTIAL_",
        "ssh-key-id": 9913xxx,
        "ssh-key-file": "~/.ssh/id_ed25519.pub",
        "ssh_key": {
          "ssh_1": {
            "id": 993xxx,
            "ssh-key-file": "~/.ssh/id_ed25519.pub",
            "fingerprint": "aa::bb:cc::dd"
          }
        },
        "server": {
          "server123": {
            "id": 39xxx,
            "status": "running",
            "access": false,
            "ip_address": "168.119.xxx.xxx",
            "location": "Nuremberg DC Park 1",
            "price": 3.29,
            "cores": 1,
            "cpu_type": "shared",
            "memory": 2,
            "disk": 20
          }
        }
      }
    }
  }

Wappler Resource Manager folders

I suggest putting the JSON inside the provider’s folder, such as:

.wappler/providers/hetzner/provider_config.json

Having this separate file allows people to add this location in .gitignore if such need arises

Wappler Resource Manager: Ability to add multiple provider identities of the same provider
Wappler Studio embedded nodejs server w/ project context
#2
#3

Maybe it is a better idea to add an option to store the API in the system keychain instead in the json file?

This way you will have API keys per user, but still the same config

#4

Weird idea.

How about embedding a small node server per project running on a specific port that can run a subset of SC actions and store in $_PROJ variables readable by the desktop app.

It could be a solution for handling any kind of secret managers and would open the door to other type of checks/permissions and features built around teams.

#5

Looks good to me, George :+1:

@JonL let’s just approve George’s suggestion so we can get this going :joy:

1 Like
#6

I need to discuss with the team in tomorrow’s stand-up.

But I can make an exception and vote for this if you vote for: