Applications

Overview

An application in Kinvey represents the backend of a single project. One Kinvey appplication may be accessed by multiple mobile, web or other clients. For example, you could have a mobile app accessing the backend and an administrative Web UI that works with the same backend.

Kinvey applications exist under a Kinvey organization. Applications assume the licensing restrictions of the organization they belong to. Only members of that organization can collaborate on the application.

Application Environments

Each Kinvey application can have multiple application environments. The environment is an instance of the app configuration and data that exists on its own. Each environment has its own ID which is used to address that environment from the Kinvey SDKs or REST API.

Using multiple environments you can model your development process in a way that allows you to test your changes before deploying them to production. A frequently-used setup is to have two environments - Development and Production. The Production environment is what your mobile app and other client applications use in production. The Development environment is what you use when you are developing new features or testing functionality.

You can clone an environment or migrate settings and data between two environments. Usually, when you are implementing some changes and validate that they work in the Development environment, you will migrate the Development environment to the Production environment.

Depending on the complexity of your project, you might need more environments, like Staging, Integration, etc. If you decide that you do not need the added complexity and functionality, you can always use only a single application environment.

Collaboration

Similar to other Kinvey entities, applications provide collaboration functionality. In order to collaborate on an application, the user needs to be a member of the organization this application belongs to.

Access control can be done either on application level or on environment level. When application level permissions are used they apply to all environments, existing and newly created. Environment-level permissions can be used to configure environment-specific access.

Application User Roles

The following user roles are available on application level:

Role name	Description	Legacy name
Viewer	Grants access to view the application and grants Viewer access to all of its environments.	N/A
Collaborator	Grants access to view the application, manage its configuration and grants Collaborator access on all of its environments.	N/A
Developer	Grants access to view the application, manage its configuration, add/remove environments and grants Developer access on all of its environments.	N/A
Administrator	Grants full access to manage the application and all of its environments.	OWNER

For more information on what Viewer, Collaborator and Developer access levels give, please look into application environment user roles section below.

The following legacy roles are also available. We do not recommend using those roles, but we have not removed them because of backward compatibility. They are suffixed with the word "_Legacy". Here is the list of legacy roles:

Role name	Description	Previous name
ADMIN_Legacy	Grants access to view the application and manage all of its environments.	ADMIN

Application Environment User Roles

The following user roles are available on application environment level:

Role name	Description	Legacy name
Viewer	Grants access to view the application environment, but not update it or access collections data.	READ_ONLY_COLLABORATOR
Collaborator	Grants access to view the application environment and manage its configuration except business logic.	RESTRICTED_COLLABORATOR
Developer	Grants access to view an application environment, manage its configuration and manage business logic.	COLLABORATOR
Administrator	Grants full access to manage an application environment.	N/A