Cloud Blog

Change in internal username format

I have a quick announcement to make today. After a recent update of WSO2 Cloud, the internal representation of usernames changed and we no longer replace the @ sign with a dot in them.

With that change, your fully qualified username now looks like email@organization_domain. For example, if my email is and my organization domain in WSO2 Cloud is wso2cloud my fully qualified username would be

As you know, in most cases, you simply log into WSO2 Cloud with your email address. This is not changing in any way.

However, there are a few cases in which the internal, fully qualified login comes into the picture:

As I already mentioned, nothing changes for regular cloud login process: you simply keep using your email address there. The change only applies to the 5 advanced scenarios listed above.

Let us know if you have any questions or concerns.

Commercial Availability of WSO2 Integration Cloud

I am happy to announce that we have just commercially launched WSO2 Integration Cloud: our platform for hosting your integration projects and API backends.

There are 5 easy monthly tiers to pick from depending on the required scale and functionality:

  • Starter is the smallest tier that can be used to host simple microservice-based project as well as Java (including JAX-RS and JAX-WS) and PHP implementations.
  • Getting Traction adds support for WSO2 Enterprise Service Bus (ESB) and Data Services, and increases the amount of resources available.
  • Medium tier lets you select your hosting region (from 12 locations around the globe), ability to scale up your applications, and gives custom docker image support,
  • Large gives multi-region support, 5 GB databases, and 48 GB of RAM for up to 16 applications.
  • Extra-Large is the enterprise package that lets you scale up to 32 applications, 192 GB of RAM, and 10 databases 10 GB each.

With all plans you can set up a VPN connection for $498 / month.

Get started with WSO2 Integration Cloud today!

WSO2 Integration Cloud Launched

We have just launched WSO2 Integration Cloud Beta. This is a service that lets you host your:

  • Cloud-to-Cloud and Cloud-to-On-Premises integration projects based on WSO2 Enterprise Service Bus (ESB) and Data Services Server (DSS),
  • Proxy services,
  • API backends developed using the integration technologies, JAX-RS, JAX-WS, or Java microservices (MSF4J),
  • Java and PHP applications,
  • MySQL databases.

You can VPN your projects to your network or leave them on the internet. You can make the service URLs public (including your custom URLs) or hide them from the internet and only access them from other services and API gateway.

We have also published documentation and tutorials to help you get started.

The service is based on WSO2 App Cloud and inherits its functionality: if you had your projects and databases in App Cloud – they have all been safely migrated to Integration Cloud.

The service is currently in free beta but will launch commercially shortly – we are literally putting in place the last changes required to make it happen.

Try WSO2 Integration Cloud today and let us know what you think via blog comments or Support menu inside the service!

Separating Development, Test, and Production

API programs typically have multiple teams involved: developers, quality assurance, acceptance testing, operations, and so on. Let us talk about the possible approaches to separating WSO2 API Cloud environments in order to give these teams the access they need while preventing them from interfering with each other’s work.

There are two main approaches that we see our customers take:

A. Setting up isolated API Cloud organizations,

B. Segregating API visibility within one organization.

Let’s look into these in detail.

Isolated API Cloud organizations

Separate API environments by provisioning separate organizations

Use this approach if you want to give your teams (for example, Developers and QC) full autonomy and reduce the risk of one team accidentally interfering with the work of another.

  1. You simply purchase separate WSO2 API Cloud subscriptions for the environments that you need. To create these extra organizations in WSO2 Cloud, click the Organization menu (in the 9-dot menu in the top-right corner) and click the Add Organization button.
  2. Upgrade each of the organizations,
  3. Invite team members to the organizations that they need.


  • You can use different subscription levels for different organizations. For example, you might need the Large subscription plan for Production but pick Starter for the Developer organization in order to optimize costs.
  • One can be a member of multiple organizations. In that case, they will be prompted to choose their organization at login.
  • You can use Export / Import functionality to move APIs between the environments.

Segregate API visibility within one organization

Separate APIs by assigning roles and setting API visibility

Choose this option if you want to fit the implementation within one subscription and are planning to assign team members to proper roles and ensure proper permissions set for each API.

  1. Create the roles that your organization has such as Developers, QA, Operations,
  2. Assign these roles to your team members,
  3. When publishing APIs, you set visibility to these roles: for example, if there is a new version of an API that is in testing, maybe only QC sees it.

In that scenario, all team members will be sharing the same WSO2 Cloud organization but the APIs and API versions that they see will depend on their role membership.

If you need any help from WSO2 on deciding which option is right for you, simply click the Support menu and ask for assistance.



Recent Posts

Most Popular Posts