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

Certificate Manager now Sends you Notifications before your Certificates Expire

Even the most successful or genius apps can fail if there are issues with availability. While development teams often engineer for availability, with lots of redundancy, health checks, and load balancing, sometimes outages occur because of simple human errors. One common error is that teams fail to renew SSL/TLS certificates on time.

Continue reading

IBM Cloud Platform now adds support for Multi-Factor Authentication

In April 2018, IBM Cloud Platform added support for Multi-Factor Authentication (MFA). This adds an extra layer of security to users’ accounts by requiring all users to provide a time-based one-time passcode in addition to their standard IBMid and password when logging in. Having this option enables IT admins to rest a little easier knowing that they’re protecting their company’s network and workloads while keeping access flexible and easy.

Continue reading

Securing Angular+Node.js Applications using App ID

One of the most common architectures of modern applications is Single Page Applications (SPAs), where a single HTML page interacts with a backend application via JavaScript to dynamically generate its content. In this blog, we look at how a single page application can integrate authentication and authorization via IBM Cloud App ID.

Continue reading