Application-Level Configuration

There are many configuration settings you can assign through the Developer Portal that can affect the behavior of your application. The settings described in this page affect behavior for the whole application or application version. These settings can be used to control things like how requests are handled and the authentication user model applied to your application.

See the component-level page for more on how to configure an application’s components.

View Settings

To view an application’s settings in the Developer Portal, select an application from the Application List and then click Configure from the top menu. When you first create an application you will be redirected to this page to further configure your new application.

Some of the settings listed here apply to the application as a whole, while some apply only to the specific application version selected at the time the settings are being edited. This means that some settings can have different values from version to version of the same application. Note that you can only change some settings while an application version is in the Definition stage, and the settings are immutable when the app version is promoted to the Sandbox or Published stage. It is important to consider what configuration of settings you would like your application to deploy with before promoting it to the Sandbox stage and subsequently Publishing it.

To view or update settings, click on a settings category to expand it. Current values for settings will be selected or displayed in input fields.  After updating any desired settings, click the Save button to the lower right, or click the Cancel button next to it to revert any changes you don’t want to keep.

Application Info

In this section you can set general descriptive information about the application, including the Application Name and Description. Note that the application Alias can’t be changed after the application is created. Changes made in this section will affect all versions of an application.

Version Info

General descriptive information about the currently-viewed application version can be set here.  The Version Name for the application version can be set, as well as information constituting the version’s Changelog.  You can’t change the Version Alias of the first version of an application. The Version Alias will be permanently set to Version 1. For all other subsequent  application versions, the Version Alias can be changed as long as that application version is in the Definition stage.

User Access

Configuration settings in this section control the application’s User Access Model.  User Access Models are enhancements to the way your application is deployed. They build on each other in that higher-level User Access Models such as Multi-tenancy require lower-level models such as Authentication and Authorization. Below is a brief description of how your application is deployed based on the highest-level model selected:

  • Anyone: the application will deploy as a single-tenant application with no Apprenda-regulated restrictions.  For instance, if the application’s website is publicly accessible, anyone will be able to launch the application. If it is restricted to an internal network, anyone with network permissions to access the site can launch the application.

  • Authenticated: the application will deploy as a single-tenant application, and Apprenda will restrict access to Platform Users.  This means that all registered Users on a given Apprenda Platform will be able to launch the application.

  • Authorized: the application will deploy as a single-tenant application, and Apprenda will restrict access to Platform Users who have been granted explicit access rights to the application.  The Development Team that deploys the application controls which Platform Users can launch and access different parts of the application through controls in the Developer Portal.

  • Multi-tenancy: the application will deploy as a multi-tenant application, and Apprenda will restrict access to Platform Users who have been granted explicit access rights to the application.  User access is controlled through subscriptions configured through the Account Portal, and can be either configured either by the Development Team that deploys the application or can be left for potential User groups to self-provision.

Note: the selection made for User Access Model will limit the choices available for other application configuration options and will also enable/disable some of the functionality described in this documentation. Please see the tables below to learn more about these restrictions.

Table 1a: Application Setting Availability by User Access Model:

User Access Model UI Deployment Strategy
Commingled app.root Commingled root/app Isolated app-tenant.root Commingled root/app/tenant
Anyone Available Available Not Available Not Available
Authenticated Available Available Not Available Not Available
Authorized Available Available Not Available Not Available
Multiple Tenants Available Available Available Available

Table 1b: Application Setting Availability by User Access Model:

User Access Model Pipeline Model Database Deployment
Integrated Classic Commingled Isolated
Anyone Available Available Not Available Available
Authenticated Available Not Available Not Available Available
Authorized Available Not Available Not Available Available
Multiple Tenants Available Available Not Available Available

Table 2: Application & Entitlement Definition Availability by User Access Model:

User Access Model Application Definitions Entitlement Definitions
Features & Additions Securbles
Anyone Not Available Not Available Not Available
Authenticated Not Available Not Available Not Available
Authorized Available Not Available Required
Multiple Tenants Available Available Required

The User Access Model setting will affect the application as a whole, and can only be modified when the app is in the Definition stage.

You can set a Login Page Style Sheet for your application in this section. When Tenants access the application URL prior to login, they will be prompted to enter their Apprenda login username and password before they are granted access to their subscribed applications. A custom stylesheet can be referenced here to customize the look of the login page that will appear when your Tenants access their applications through this method.

For more information on creating a custom stylesheet, download the Custom Login Style Guide available as a ZIP file from the Develop Portal. The example is available in the help bubble that opens when hovering over the question mark next to Login Page Style Sheet.

Once you have created and customized your stylesheet and uploaded the resulting CSS file to a URL you control, you must specify the stylesheet URL in the Login Page Style Sheet field.


In this section you can define the tags and classifications relating to how your application is deployed.

The Cloud Affinity setting lets you choose which Cloud your application’s components is deployed to. All available Clouds will appear in the drop-down list. If you select, “No Preference” from the drop-down list, the Platform will deploy the application to any of the available servers in any cloud. When you change the Cloud Affinity setting for an application, any already-deployed components will be migrated to the new Cloud immediately.

Note that the option to configure Cloud Affinity is disabled Platform-wide by default. This setting will only be visible if the Platform is installed on a Hybrid Cloud environment and your Platform Operator has enabled the setting.

Custom Properties can also be defined for the application version here. Custom Properties are tags that are applied to application versions and individual application components. Custom Properties are defined by Platform Operators and your ability to edit them or if they are required for deployment depend on the configuration options set when a given property was created. Depending on the rules your Platform Operator has configured for Platform behavior, the way you apply Custom Properties tags to an application or app component may affect how that object is hosted on the Platform, but won’t affect that object’s behavior. 

Custom Properties that have values set or are required for deployment for your application will always be visible in this section of the Developer Portal. Custom Properties that are both unused and not required can be viewed/hidden using the appropriate link. It’s also possible that no Custom Properties are listed here. 

Cloud Affinity and Custom Properties settings can be modified for an application version at any point in its Lifecycle.


Settings related to the application’s UI and data architecture can be updated here.

The URL Type and UI Model settings determine how the app’s User Interfaces are deployed and accessed, and can only be set when the application is in the Definition stage.  For applications with Multi-tenancy, you can choose either a Commingled UI Model, which will map all Tenants to one website, or an Isolated UI Model, which will create a unique website for each Tenant (for Java Web Applications, only Commingled UI Model is available).  Applications with a lower-level User Access Model are also limited to the Commingled UI deployment model, as multi-tenant website creation is not relevant for these applications. 

Note that All Multi-Tenant applications will use the Commingled Model, and the UI Model option will not appear in the Architecture section.

Each deployment model offers a choice of URL Type (unless your Platform Operator has restricted this choice):

Commingled UI Model URL Types:

  • Subdomain (http://app.rooturl)
  • Path (http://apps.rooturl/app)

Isolated UI Model URL Types:

  • Subdomain (http://app-tenant.rooturl)
  • Path (http://apps.rooturl/app/tenant)

In the schemes above, “app”=application alias, “rooturl”=the url of your Platform instance, and “tenant”=the Tenant’s Organization alias.  The settings you choose will be reflected in the Application URL display, which shows the Apprenda-generated application URL that can be used to access the application directly.  (Please Note:  your Tenants can always access their Multi-tenant and applications through the Applications page of their Account Portal by clicking on the Launch icon to the right of the desired application.)

In addition you can provide your Tenants with an Application Vanity URL controlled by your Development Team that has been configured via DNS to access your application once it has been promoted to the Published stage.  With this URL set, the Platform will honor requests from your URL to link to the application URL hosted on your Platform instance after your application is published (the Application Vanity URL will not work when the application is in the Sandbox stage) and your Domain Administrator has made the necessary DNS configurations. A TLS/SSL certificate may be used by your Application Vanity URL and can be uploaded through the Request Handling settings described in the next section.

Please note that on a Hybrid Cloud environment, the UI for an application accessed via an Application Vanity URL must be located on the Cloud for which the DNS entry has been configured.

Finally, your application’s Data Model and Database Provider can be configured here.  For applications with Multi-tenancy, the Data Model setting determines how Tenant data will be stored.  You can choose either a Commingled Database model, which stores data from multiple Tenants in the same database and conserves resources because the number of Tenants does not determine the number of databases, or an Isolated Database model, which creates a physical database for each Tenant.  Applications with a lower-level User Access Model set will automatically be deployed with an Isolated Database model, as multi-tenant data storage is not relevant for these applications.

Additionally, you can view and change the Database Provider that the application will use as its relational database store; currently, SQL Server and Oracle are the supported options.  If an application archive has already been uploaded, the Platform will auto-detect the Database Provider that the app’s database component has been configured for.

These settings affect the application as a whole; once you have promoted your application to the Sandbox stage, you will not be able to change the Data Model and Database Provider options.

Request Handling

The handling of User access requests and UI sessions can be configured here. Request Handling settings can be modified for an application version at any point in its Lifecycle.

The Application Security setting allows you to choose whether to Force Secure (https) Access when a User attempts to access your application using an insecure (http) protocol.  If this option is checked, the Platform will automatically redirect the access attempt to an equivalent secure (https) URL.

Under the Web Session heading you can choose to enable session replication and sticky sessions for an application version.

The Enable Session Replication option will cause the Platform to store HTTP session information for any UI sessions created for the application in Apprenda’s distributed cache and preserve it in the event of a node failure. Note that the Platform has the ability to run more than one instance of a .NET application’s UI component on the same server. To deploy .NET UI components in this way, the application version cannot have session replication enabled.

The Enable Sticky Sessions option will guarantee that all User requests for a particular UI session are serviced by the same UI instance.

The Managed Pipeline mode can be configured only for applications that don’t require User authentication.  In that case, Classic or Integrated mode can be selected; otherwise, Integrated mode will be set.

If an Application Vanity URL is set in the Architecture settings, you will also see a Front-End Load Balancer heading appear. Use Preserve URL when you want to maintain the custom hostname for the entire session (this is most common). Use Create Redirect Rule if you prefer to use the native URL provided by the platform, which can be useful, if you want to ‘pin’ a client against a particular location.

Note: If an Application Vanity URL is assigned to a JBoss application in the Publish stage, the application will only be accessible through the assigned vanity URL. A Platform assigned application URL will not be designated and, if chosen, the Create Redirect Rule option under Front-End Load Balancer will be ignored.

Certificates for Application Vanity URLs

You can add a TLS/SSL certificate to your Application Vanity URL. Depending on how your Platform is configured, certificates for applications with a Application Vanity URL are either required, optional, or disabled. Consult your Platform Operator if you have questions about certificate requirements on your Platform. It should be noted that only Developers that have been granted the Manage Certificates securable can upload, edit, or remove a certificate. Certificates can also be uploaded with application archives and edited through these settings.

Upload Certificate

To upload a certificate click Select File under Certificate. The certificate must be a PFX certificate archive. If the certificate requires a password, enter it in the input box that appears. Be sure to Save your changes from the bottom menu to upload the certificate to the Platform.

Once the certificate has been successfully uploaded, you will see the Domain Name and Valid Date Range of the certificate under the Certificate section. Additionally, if the certificate is within 2 weeks of expiring an alert message will appear on this page.

View Certificate

To see more information about the certificate, click the box with certificate details and an expanded summary window will open.

Replace Certificate

To update the current certificate, click Replace and selected a new certificate file to upload and apply to the application.

Remove Certificate

To remove the current certificate, click Remove. If certificates are required for applications with vanity URLs assigned, you will not be able to remove a certificate if the application is published. Instead, you must replace the current certificate with another certificate if you wish to make changes to the current certificate.