Feature request: hands-off CCaaS

[joaormatos]

I would like the ability to start CCaaS servers manually and have Fablo just generate and install the CCaaS packages containing metadata and connection information.

The motivation is being able to easily start CCaaS instances directly from an IDE with a debugger.

Crude workaround

I managed to get it working manually, for a single peer and chaincode.
I leave the steps I took here as an inspiration for others in the same situation.

First I started Fablo normally, with a regular chaincode definition in the config.
Then I did something like this:

metadata.json:

{
  "path":"",
  "type":"ccaas",
  "label":"mycc"
}

connection.json:

{
  "address": "172.17.0.1:10000",
  "dial_timeout": "10s",
  "tls_required": false
}

Where 172.17.0.1 is the IP address of the host as seen from the peer's container and 10000 is the port I chose to have the chaincode listening on.
I got the address with ip addr show docker0 on the host.

# Create and install package
tar czf code.tar.gz connection.json
tar czf package.tar.gz metadata.json code.tar.gz
cp package.tar.gz fablo-target/fabric-config/chaincode-packages/
docker exec -e CORE_PEER_ADDRESS=peer0.org1.example.com:7041 cli.org1.example.com peer lifecycle chaincode install /var/hyperledger/cli/chaincode-packages/package.tar.gz
# Re-issue the approveformyorg command so that the peer starts using the newly installed package
# No commit is necessary because Fablo already did that and I didn't change any parameters besides --package-id 
pkgid="$(docker exec -e CORE_PEER_ADDRESS=peer0.org1.example.com:7041 cli.org1.example.com peer lifecycle chaincode calculatepackageid /var/hyperledger/cli/chaincode-packages/package.tar.gz)"
docker exec -e CORE_PEER_ADDRESS=peer0.org1.example.com:7041 cli.org1.example.com peer lifecycle chaincode approveformyorg -o orderer0.group1.orderer.example.com:7030 -C my-channel1 -n mychaincode -v 0.0.1 --package-id "$pkgid" --sequence 1

Finally, I started the chaincode in vscode with a launch.json looking something like this:

{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "My Chaincode for Org1",
      "type": "go",
      "request": "launch",
      "mode": "auto",
      "env": {
        "CORE_PEER_TLS_ENABLED": "false",
        "CORE_CHAINCODE_ID_NAME": "mycc:49009f43ca0943550cea0b6341aa51f39e0931fe1b5b64fba07ea13cac683ff9",
        "CHAINCODE_SERVER_ADDRESS": "172.17.0.1:10000"
      },
      "program": "${workspaceFolder}/chaincodes/mychaincode"
    }
  ]
}

This was a very crude workaround, but for now it's working how I want it to and it's starting to approach a decent development experience.

I can now rapidly iterate on the code, set logpoints, breakpoints, step through the execution, inspect the call stack....
All that good stuff.

[dzikowski]

Hi @joaormatos thanks for the suggestion. Indeed it would be useful to support manual start of CCaaS containers -- and we're going to work on that.

I'd like to also suggest something that might work for you to achieve the ability to start the chaincode process manually, and at the same time is more straightforward.

From the command provided, it seems there is no TLS, and Fabric 2.x, and for that flow Fablo supports peer dev mode, which might be a perfect fit for your use case. This is the sample Fablo config I've just verified (run fablo init node, and then update the fablo-config.json):

{
  "$schema": "https://github.com/hyperledger-labs/fablo/releases/download/2.4.3/schema.json",
  "global": {
    "fabricVersion": "2.5.11",
    "tls": false,
    "peerDevMode": true,
    "engine": "docker"
  },
  "orgs": [
    {
      "organization": {
        "name": "Orderer",
        "domain": "orderer.example.com",
        "mspName": "OrdererMSP"
      },
      "ca": {
        "prefix": "ca",
        "db": "sqlite"
      },
      "orderers": [
        {
          "groupName": "group1",
          "type": "solo",
          "instances": 1,
          "prefix": "orderer"
        }
      ]
    },
    {
      "organization": {
        "name": "Org1",
        "domain": "org1.example.com",
        "mspName": "Org1MSP"
      },
      "ca": {
        "prefix": "ca",
        "db": "sqlite"
      },
      "orderers": [],
      "peer": {
        "instances": 1,
        "db": "LevelDb",
        "prefix": "peer"
      }
    }
  ],
  "channels": [
    {
      "name": "my-channel1",
      "orgs": [
        {
          "name": "Org1",
          "peers": [
            "peer0"
          ]
        }
      ]
    }
  ],
  "chaincodes": [
    {
      "name": "chaincode1",
      "version": "0.0.1",
      "channel": "my-channel1",
      "lang": "node",
      "directory": "./chaincodes/chaincode-kv-node"
    }
  ]
}

In this case when you start the network with fablo up, it doesn't start chaincode containers/processes at all. You need to do it manually. For the Node sample provided in ./chaincodes/chaincode-kv-node, there is the following script in package.json:

  "scripts": {
    ...
    "start:dev": "fabric-chaincode-node start --peer.address \"127.0.0.1:8541\" --chaincode-id-name \"chaincode1:0.0.1\" --tls.enabled false",
    "start:watch": "nodemon --exec \"npm run start:dev\"",
    ...
  },

With that sample you can just run npm run start:dev:

➜  chaincode-kv-node git:(main) ✗ npm run start:dev

> chaincode-kv-node@0.2.0 start:dev
> fabric-chaincode-node start --peer.address "127.0.0.1:8541" --chaincode-id-name "chaincode1:0.0.1" --tls.enabled false

2026-01-09T12:58:23.151Z info [c-api:contracts-spi/bootstrap.js]                  No metadata file supplied in contract, introspection will generate all the data  
2026-01-09T12:58:23.171Z info [c-api:lib/chaincode.js]                            Registering with peer 127.0.0.1:8541 as chaincode "chaincode1:0.0.1"  
2026-01-09T12:58:23.175Z info [c-api:fabric-shim/cli]                             Bootstrap process completed  
2026-01-09T12:58:23.201Z info [c-api:lib/handler.js]                              Successfully registered with peer node. State transferred to "established"  
2026-01-09T12:58:23.202Z info [c-api:lib/handler.js]                              Successfully established communication with peer node. State transferred to "ready"

But it can be any custom command that starts the chaincode, so it should be fairly straightforward to use debugging or nodemon/watch/hot-reload-mode. Would it work for you?

[dzikowski]

oh, is this the reason why you decided to use CCaaS instead of dev mode? #643

[joaormatos]

@dzikowski Yes, CCaaS was the best alternative I could think of once I realized that I wouldn't be able to interact with the chaincode in any way that relied on discovery.

[joaormatos]

Now that I've had more time to think, I realize there may be a simpler workaround: get Fablo to run a container that accepts the connection and proxies it to wherever I want it to go.

socat should be able to handle something like that.

Another idea I had is writing a proxy application that bridges the connection between a peer that's looking for a CCaaS server and a chaincode that's looking for a peer in dev mode, but I need to get a better understanding of peer-chaincode communication to tell if it'd be as simple as it sounds.

[dzikowski]

I wonder if it is also possible to use CCaaS anyway. When you create a CCaaS hot-reload sample with:

fablo init node dev

It gives you a Node.js chaincode with the following config:

  "chaincodes": [
    {
      "name": "chaincode1",
      "version": "0.0.1",
      "channel": "my-channel1",
      "lang": "ccaas",
      "image": "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}",
      "chaincodeMountPath": "$CHAINCODES_BASE_DIR/chaincodes/chaincode-kv-node",
      "chaincodeStartCommand": "npm run start:watch:ccaas",
      "privateData": []
    }
  ],

It effectively means, that it uses chaincodeMountPath as a path of the source code (it is mounted into the CCaaS container), and chaincodeStartCommand is used as a command to start the chaincode. In this scenario you have hot-reload, and the ability to debug with console.log etc. out of the box.

But you may also try to update the chaincodeStartCommand to run debug mode, and use Fablo post-generate hook to expose debugger port (perl/sed on the generated docker compose file in fablo-target). This way it might be possible to run it even with the IDE debugger, while keeping everything in a single Fablo config file.

[joaormatos]

I'm working with Go chaincode, so I'll need to tweak a few things, but that might be a working strategy.

I'll give it a try.

[joaormatos]

But you may also try to update the chaincodeStartCommand to run debug mode, and use Fablo post-generate hook to expose debugger port (perl/sed on the generated docker compose file in fablo-target).

I tried looking into it and found that the CCaaS containers aren't defined in the docker compose file.

They're instead being referenced directly in fablo-target/fabric-docker/commands-generated.sh, inside of the installChaincodes, installChaincode and upgradeChaincode functions, and being started directly with docker run.

The CCaaS containers (and images...?) are also being removed manually, in networkDown, with some recourse to globbing on names.

  printf "Removing chaincode containers & images... \U1F5D1 \n"
  for container in $(docker ps -a | grep "peer0.org1.example.com.*chaincode1" | awk '{print $1}'); do
    echo "Removing container $container..."
    docker rm -f "$container" || echo "docker rm of $container failed. Check if all fabric dockers properly was deleted"
  done
  for image in $(docker images "peer0.org1.example.com.*chaincode1*" -q); do
    echo "Removing image $image..."
    docker rmi "$image" || echo "docker rmi of $image failed. Check if all fabric dockers properly was deleted"
  done
  for container in $(docker ps -a | grep "peer1.org1.example.com.*chaincode1" | awk '{print $1}'); do
    echo "Removing container $container..."
    docker rm -f "$container" || echo "docker rm of $container failed. Check if all fabric dockers properly was deleted"
  done
  for image in $(docker images "peer1.org1.example.com.*chaincode1*" -q); do
    echo "Removing image $image..."
    docker rmi "$image" || echo "docker rmi of $image failed. Check if all fabric dockers properly was deleted"
  done

They're not being handled in stopNetwork/startNetwork however.

Perhaps it would make more sense to define CCaaS in a separate docker compose file, and have labels applied so that they can be more accurately targeted for stop, start and remove.

Another thing that looked wrong to me as I was following along commands-generated.sh was that the CCaaS metadata package was being created twice:

    chaincodePackageCCaaS "cli.org1.example.com" "peer0.org1.example.com" "chaincode1" "$version" "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}" "17041" "ccaas_peer0.org1.example.com_my-channel1_chaincode1_0.0.1" "true" "my-channel1" "org1.example.com"
    chaincodePackageCCaaS "cli.org1.example.com" "peer1.org1.example.com" "chaincode1" "$version" "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}" "17042" "ccaas_peer1.org1.example.com_my-channel1_chaincode1_0.0.1" "true" "my-channel1" "org1.example.com"

Where both commands output to fablo-target/fabric-config/chaincode-packages/my-channel1_chaincode1_0.0.1.tar.gz

And then installed on both peers:

    chaincodeInstall "cli.org1.example.com" "peer0.org1.example.com:7041" "chaincode1" "$version" "my-channel1" "crypto-orderer/tlsca.orderer.example.com-cert.pem"
    startCCaaSContainer "peer0.org1.example.com:7041" "chaincode1" "my-channel1_chaincode1_$version" "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}" "17041" "cli.org1.example.com" "crypto-orderer/tlsca.orderer.example.com-cert.pem" "ccaas_peer0.org1.example.com_my-channel1_chaincode1_0.0.1" "$CHAINCODES_BASE_DIR/chaincodes/chaincode-kv-node" "npm run start:watch:ccaas"
    chaincodeInstall "cli.org1.example.com" "peer1.org1.example.com:7042" "chaincode1" "$version" "my-channel1" "crypto-orderer/tlsca.orderer.example.com-cert.pem"
    startCCaaSContainer "peer1.org1.example.com:7042" "chaincode1" "my-channel1_chaincode1_$version" "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}" "17042" "cli.org1.example.com" "crypto-orderer/tlsca.orderer.example.com-cert.pem" "ccaas_peer1.org1.example.com_my-channel1_chaincode1_0.0.1" "$CHAINCODES_BASE_DIR/chaincodes/chaincode-kv-node" "npm run start:watch:ccaas"

And approved for the org:

    chaincodeApprove "cli.org1.example.com" "peer0.org1.example.com:7041" "my-channel1" "chaincode1" "$version" "orderer0.group1.orderer.example.com:7030" "AND ('Org1MSP.member')" "" "crypto-orderer/tlsca.orderer.example.com-cert.pem" "" "ccaas" "hyperledger/fabric-nodeenv:${FABRIC_NODEENV_VERSION:-2.5}"

I think this means that both peer0.org1.example.com and peer1.org1.example.com will end up connecting to the second CCaaS instance, intended for only peer1.

Having multiple instances of the same CCaaS chaincode running for the same organization might be a bit more complicated, since all peers in an org have to reference the same CCaaS metadata package. I haven't looked into how to do that yet.

[joaormatos]

Found the relevant documentation:

https://hyperledger-fabric.readthedocs.io/en/latest/cc_basic.html#running-with-multiple-peers

The connection.json that is being generated twice and looks like this:

{ 
      "address": "ccaas_peer1.org1.example.com_my-channel1_chaincode1_0.0.1:7052",
      "domain": "ccaas_peer1.org1.example.com_my-channel1_chaincode1_0.0.1",
      "dial_timeout": "10s",
      "tls_required": true,
      "client_auth_required": true,
      "client_cert": "-----BEGIN CERTIFICATE-----\nMIICaDCCAg6gAwIBAgIRALsmcS1/OgMJXVDEpn/xqwswCgYIKoZIzj0EAwIwdjEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHzAdBgNVBAMTFnRs\nc2NhLm9yZzEuZXhhbXBsZS5jb20wHhcNMjYwMTEyMTUzNDAwWhcNMzYwMTEwMTUz\nNDAwWjBbMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UE\nBxMNU2FuIEZyYW5jaXNjbzEfMB0GA1UEAxMWcGVlcjEub3JnMS5leGFtcGxlLmNv\nbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABDkmN2B1EhdFl+M1M/RYk8gXFyNI\nfIDLXxkYBpIs2/WZT3VIAmbsheHXagEaE5zJ1RwTGFIbuqeq75XMurEvB0GjgZcw\ngZQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD\nAjAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKAIPSRjF5eCgcg3WHInEEL3p9QckMq\nEjL2uWC3JdeK6xTJMCgGA1UdEQQhMB+CFnBlZXIxLm9yZzEuZXhhbXBsZS5jb22C\nBXBlZXIxMAoGCCqGSM49BAMCA0gAMEUCIQDp7wJ1wBo3ygOMuMwYwjTHfRfc7q6b\nXXMtXh1KNJMPpgIgKSwsa+eCe5vj9+GIEMi5FmWPzpTaQWkFz6YiAmBnTZY=\n-----END CERTIFICATE-----\n",
      "client_key": "-----BEGIN PRIVATE KEY-----\nMIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgafTOTv1wcl3xF3bN\nTFIxv1kfP5QMJT2lQw3RaaWLvSahRANCAAQ5JjdgdRIXRZfjNTP0WJPIFxcjSHyA\ny18ZGAaSLNv1mU91SAJm7IXh12oBGhOcydUcExhSG7qnqu+VzLqxLwdB\n-----END PRIVATE KEY-----\n",
      "root_cert": "-----BEGIN CERTIFICATE-----\nMIICVjCCAf2gAwIBAgIQQQpcwULVCE3cnUT9jk25rTAKBggqhkjOPQQDAjB2MQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEfMB0GA1UEAxMWdGxz\nY2Eub3JnMS5leGFtcGxlLmNvbTAeFw0yNjAxMTIxNTM0MDBaFw0zNjAxMTAxNTM0\nMDBaMHYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH\nEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBvcmcxLmV4YW1wbGUuY29tMR8wHQYD\nVQQDExZ0bHNjYS5vcmcxLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0D\nAQcDQgAEsJ79/T3ki+04iFKbKf6a2CgodPeZDM0bEMB+/2oe5J3F8UyQk9OixICf\nl9mgKxd2pDdmPhf2/3+uHjBLZML+xqNtMGswDgYDVR0PAQH/BAQDAgGmMB0GA1Ud\nJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MCkGA1Ud\nDgQiBCD0kYxeXgoHIN1hyJxBC96fUHJDKhIy9rlgtyXXiusUyTAKBggqhkjOPQQD\nAgNHADBEAiA0eyDDFRM0jn9+k4q/f1bYg6hn+o/S0n0UOyoGjfrRSQIgYfhPXE9q\n/8KqpaixgTGKhWq5IAy23Kn4bHB72AtMrRY=\n-----END CERTIFICATE-----\n"
    }

Could instead look something like this:

{ 
      "address": "ccaas_{{.peername}}_my-channel1_chaincode1_0.0.1:7052",
      "domain": "ccaas_{{.peername}}_my-channel1_chaincode1_0.0.1",
      "dial_timeout": "10s",
      "tls_required": true,
      "client_auth_required": true,
      "client_cert": "{{.my-channel1_chaincode1_0.0.1.clientCert}}",
      "client_key": "{{.my-channel1_chaincode1_0.0.1.clientKey}}",
      "root_cert": "{{.my-channel1_chaincode1_0.0.1.rootCert}}"
 }

Then each peer would need an additional environment variable, like this:

CHAINCODE_AS_A_SERVICE_BUILDER_CONFIG="{\"peername\":\"peer1.org1.example.com\", \"my-channel1_chaincode1_0.0.1\": {\"clientCert\": -----BEGIN CERTIFICATE-----\nMIICaDCCAg6gAwIBAgIRALsmcS1/OgMJXVDEpn/xqwswCgYIKoZIzj0EAwIwdjEL\nMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExFjAUBgNVBAcTDVNhbiBG\ncmFuY2lzY28xGTAXBgNVBAoTEG9yZzEuZXhhbXBsZS5jb20xHzAdBgNVBAMTFnRs\nc2NhLm9yZzEuZXhhbXBsZS5jb20wHhcNMjYwMTEyMTUzNDAwWhcNMzYwMTEwMTUz\nNDAwWjBbMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UE\nBxMNU2FuIEZyYW5jaXNjbzEfMB0GA1UEAxMWcGVlcjEub3JnMS5leGFtcGxlLmNv\nbTBZMBMGByqGSM49AgEGCCqGSM49AwEHA0IABDkmN2B1EhdFl+M1M/RYk8gXFyNI\nfIDLXxkYBpIs2/WZT3VIAmbsheHXagEaE5zJ1RwTGFIbuqeq75XMurEvB0GjgZcw\ngZQwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcD\nAjAMBgNVHRMBAf8EAjAAMCsGA1UdIwQkMCKAIPSRjF5eCgcg3WHInEEL3p9QckMq\nEjL2uWC3JdeK6xTJMCgGA1UdEQQhMB+CFnBlZXIxLm9yZzEuZXhhbXBsZS5jb22C\nBXBlZXIxMAoGCCqGSM49BAMCA0gAMEUCIQDp7wJ1wBo3ygOMuMwYwjTHfRfc7q6b\nXXMtXh1KNJMPpgIgKSwsa+eCe5vj9+GIEMi5FmWPzpTaQWkFz6YiAmBnTZY=\n-----END CERTIFICATE-----\n\", \"clientKey\": \"-----BEGIN PRIVATE KEY-----\nMIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgafTOTv1wcl3xF3bN\nTFIxv1kfP5QMJT2lQw3RaaWLvSahRANCAAQ5JjdgdRIXRZfjNTP0WJPIFxcjSHyA\ny18ZGAaSLNv1mU91SAJm7IXh12oBGhOcydUcExhSG7qnqu+VzLqxLwdB\n-----END PRIVATE KEY-----\n\", \"rootCert\":\"-----BEGIN CERTIFICATE-----\nMIICVjCCAf2gAwIBAgIQQQpcwULVCE3cnUT9jk25rTAKBggqhkjOPQQDAjB2MQsw\nCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZy\nYW5jaXNjbzEZMBcGA1UEChMQb3JnMS5leGFtcGxlLmNvbTEfMB0GA1UEAxMWdGxz\nY2Eub3JnMS5leGFtcGxlLmNvbTAeFw0yNjAxMTIxNTM0MDBaFw0zNjAxMTAxNTM0\nMDBaMHYxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQH\nEw1TYW4gRnJhbmNpc2NvMRkwFwYDVQQKExBvcmcxLmV4YW1wbGUuY29tMR8wHQYD\nVQQDExZ0bHNjYS5vcmcxLmV4YW1wbGUuY29tMFkwEwYHKoZIzj0CAQYIKoZIzj0D\nAQcDQgAEsJ79/T3ki+04iFKbKf6a2CgodPeZDM0bEMB+/2oe5J3F8UyQk9OixICf\nl9mgKxd2pDdmPhf2/3+uHjBLZML+xqNtMGswDgYDVR0PAQH/BAQDAgGmMB0GA1Ud\nJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAPBgNVHRMBAf8EBTADAQH/MCkGA1Ud\nDgQiBCD0kYxeXgoHIN1hyJxBC96fUHJDKhIy9rlgtyXXiusUyTAKBggqhkjOPQQD\nAgNHADBEAiA0eyDDFRM0jn9+k4q/f1bYg6hn+o/S0n0UOyoGjfrRSQIgYfhPXE9q\n/8KqpaixgTGKhWq5IAy23Kn4bHB72AtMrRY=\n-----END CERTIFICATE-----\n\"}}"

I'm aware that having a huge environment variable with a bunch of certificate and key material is ugly, but I didn't find a better option.

I first considered the possibility of storing certificate/key data in the filesystem, with an additional mountpoint, but unfortunately the connection.json file requires that data to exist as a PEM-encoded string, and the "ccaas_builder" external builder included with peer images doesn't provide any facility to load data from files when processing templates in connection.json.

https://github.com/hyperledger/fabric/blob/68ca620a28cee50f59805cb1fceef48f0acae66c/ccaas_builder/cmd/build/main.go#L178

Though it could be easily modified to do that, by adding a file-loading template function, so the template could instead read something like:

{ 
      "address": "ccaas_{{.peername}}_my-channel1_chaincode1_0.0.1:7052",
      "domain": "ccaas_{{.peername}}_my-channel1_chaincode1_0.0.1",
      "dial_timeout": "10s",
      "tls_required": true,
      "client_auth_required": true,
      "client_cert": "{{loadFile \"/somePath/my-channel1/chaincode1/0.0.1/client.crt\"}}",
      "client_key": "{{loadFile \"/somePath/my-channel1/chaincode1/0.0.1/client.key\"}}",
      "root_cert": "{{loadFile \"/somePath/my-channel1/chaincode1/0.0.1/root.crt\"}}"
 }

[joaormatos]

I'm aware that having a huge environment variable with a bunch of certificate and key material is ugly, but I didn't find a better option.

I realized a (maybe) better option.
Use conditionals in the templates included in metadata.json:

{ 
      "address": "ccaas_{{.peername}}_my-channel1_chaincode1_0.0.1:7052",
      "domain": "ccaas_{{.peername}}_my-channel1_chaincode1_0.0.1",
      "dial_timeout": "10s",
      "tls_required": true,
      "client_auth_required": true,
      "client_cert": "{{if eq .peername \"peer0.org1.example.com\"}}<CERT-FOR-PEER0>{{else if eq .peername \"peer1.org1.example.com\"}}<CERT-FOR-PEER1>{{end}}",
      "client_key": "{{if eq .peername \"peer0.org1.example.com\"}}<KEY-FOR-PEER0>{{else if eq .peername \"peer1.org1.example.com\"}}<KEY-FOR-PEER1>{{end}}",
      "root_cert": "{{if eq .peername \"peer0.org1.example.com\"}}<ROOTCERT-FOR-PEER0>{{else if eq .peername \"peer1.org1.example.com\"}}<ROOTCERT-FOR-PEER1>{{end}}"
 }

This way each peer just needs an environment variable with its own name:

CHAINCODE_AS_A_SERVICE_BUILDER_CONFIG="{\"peername\":\"peer1.org1.example.com\"}"

The disadvantage of course is that peers will have access to the CCaaS keys of all other peers in the same org, if they also have the chaincode installed. Not something you'd want in production, but maybe it's fine here.

I don't think a more elegant alternative is possible without adding a custom external builder, disabling TLS or making all peers in the same org just share the same key material.

[joaormatos]

Better option still: keep it simple and don't use TLS in CCaaS connections. Turns out that it's optional, even if TLS is enabled for the network. I just tested that in a staging network.

Makes sense. It'd be superfluous to use TLS if the network path is secure.

That brings up the question: should you just remove the code that implements TLS in CCaaS connections?

As I see it, the only real point in enabling TLS in a local Docker deployment would be to exercise the peer and CCaaS server's ability to use TLS in their connection.

I only see that having value for:

• testing relevant code in a peer or chaincode shim implementation
• a learner using Fablo to generate an example of a CCaaS deployment that uses TLS, to learn how that works
• performance tests requiring the presence of TLS overhead in CCaaS connections

Whereas the pros for dropping TLS in CCaaS would be:

• less code to maintain
• faster to install CCaaS chaincode (due to skipping cert generation)
• no TLS overhead in CCaaS comms

Should probably open a separate issue for this.