Cloning an App ID instance configuration

Share this post:

With App ID, you can now manage your service instance with an API!

Cool, right?

But even better than that, you can use the management API to create a script that copies an instance configuration from one service instance to another. This means that you don’t have to assign service access roles in each instance, you can do the work once, and then replicate it. You can integrate this script as part of your DevOps pipeline.

But, how do I do that while making sure I’m still giving the right people, the right access?

Glad you asked.

In this blog, we will walk you through using a script to obtain an API-key, and limited Identity and Access Management (IAM) credentials that you can use to access the App ID APIs.


  • You must be the owner of your IBM Cloud account, or have the appropriate IAM access policy in it, at least for App ID type resources. See this documentation for information about IAM access policies.
  • Python must be installed. If you are working on a Mac or Linux machine, you may already have it installed. If not, you can use the provided link.
  • An App ID service instance that you have Administrator level of access to. From now on, we’ll refer to this instance as the source instance.
  • A second App ID service instance in the same account, which you have Administrator level of access to. Going forward, this instance will be known as the target instance.

Obtaining a service ID and API-key

  1. As an account owner or Administrator, log into the IBM Cloud console and create a new service ID. Navigate to Manage > Security > Identity and Access and then select Service IDs. For a detailed walkthrough of creating and managing service IDs, check out this blog.
  2. Create an API-key for the service ID that you created previously. You’ll need to pass this key to the DevOps person who operates the cloning task.

    Tip: For simplicity, this example shows how to clone an instance in the same account as the source.
    To clone to another account, you can create 2 service IDs and API-keys; one in your source account and the other in your target account.

Assigning access policies

For the service ID, create these two access policies

  1. For the  App ID source instance assign the role of Reader.
  2. For the App ID target instance assign the the role of Writer.

Tip: Be sure that you only give the service ID the rights to complete the tasks that you want it to. If you give too much, the ID has the ability to affect more than you intend. To learn more about App ID actions and roles, check out our doc on service access management.

Installing the cloning script

Working with the CLI, complete the following steps.

  1. Clone the repository.
    git clone
  2. Change into the script folder.
    cd appid-samples/cloning-instance-with-rest
  3. Install the script.
    sudo python install

Running the cloning script

  1. Review the configurable parameters.
  2. Run the following command to start the script.
    appidc <source_id> <target_id> --apikey <api_key> --region <source_region> --target_region <target_region>
Parameter Explanation
source_id The tenantID of the source instance of App ID that you want to clone.
target_id The tenantID of the target instance of App ID that you want to copy the configuration to.
api_key The API key used to create an IAM token with sufficient privileges.
source_region The region that the instance of App ID that you want to clone is located in. If not provided, the default is US-South.
target_region The region that the instance of App ID that you want to copy the configuration to is located in. If not provided, it will default to the source region.

Tip: To see the REST messages, append the -v flag to the command.

So, say you have App ID instance, x, that you have configured exactly as you want it but you need the same configuration in instance y. Both instances of the service are located in the IBM Cloud UK region. What would that command look like? Check out the following example.


appidc xxxxxxx yyyyyyy --apikey KkKkKkKkkKkKkKkKk --region eu-gb

And that’s it!

To go even further with App ID and access management, check out our documentation!



Cloud Security, App ID Architect

More Security stories
February 26, 2019

Enabling Helm with TLS and Service Accounts

Transport Layer Security (TLS) and service accounts—when used together— can greatly improve the security and flexibility of whatever application you choose to run on your cluster with IBM Cloud Data Shield.

Continue reading

February 12, 2019

The State of IBM Cloud Security: Think 2019

Traditional security products are not designed to address the challenges of dynamic, virtual, and distributed cloud environments. IBM’s view is that enterprises today require an end-to-end approach to security that helps them achieve three core objectives in managing their risk and compliance through structured security practices.

Continue reading

February 11, 2019

Announcing IBM Cloud Data Shield Beta at Think 2019

Since we announced IBM Cloud Data Shield experimental, we have been hard at work helping our early adopters (Irene Energy and iExec) develop their Zero Trust platforms and building the next version of Data Shield. Today, we are excited to announce Data Shield beta!

Continue reading