Note: This document is based on Jelastic version 3.3
The system of quotas at Jelastic is intended for setting limits on particular options, resources and account usage for users while working with a platform.
These limitations can be regulated by cluster administrators via JCA:
- for groups - at the Billing > Groups > Quotas tab
for separate users - by selecting the necessary customer within the Users section and switching to the Quotas tab at the pane to the right
Herewith, the list of quotas at these tabs can vary, as well as for the different types of groups. The main limitations, stated for a particular account, can be found by a user within the Quotas&Pricing information window at the Jelastic dashboard.
Use the table below to get acquainted with all the existing quotas (sorted alphabetically) and their descriptions. The values, specified within the columns for specific group types, are used by default or stated as an example for a particular option’s usage.
This quota regulates the sequence of charging the accounts. If the value is 1, the main balance is charged first. And if the value is 0, the first of all the bonuses are used and only then, the money from the main balance
State 1 if you’d like to enable account upgrade to the billing group only when its balance is funded (but not just after submitting the Upgrade form).
Set as 1 to enable obligatory account conversion to billing group right after registration.
The period after which the deactivated account becomes destroyed
The minimum amount of funds (according to the currency used), that should be present at the account balance for a user to be allowed to create an environment.
When account balance drops below this value, Jelastic starts to send warning emails to the end-user. Set this quota to 0 for disabling these notifications.
Amount of bonuses (according to the currency used) a user gets for using a trial account. After all the bonuses are spent, such an account will be deactivated. To avoid the subsequent destroy of the account, it should be converted to the billing one.
The period during which a trial account can be used. After the end of this period a trial account is deactivated. To avoid the subsequent destroy of the account, it should be converted to the billing one.
The value of this quota can be also set to “-1” for disabling the trial period limitation by the amount of days.
The period of time for transferring money to the account after its upgrade. It is used to avoid unnecessary deactivation while waiting for the payment completion.
bonus.fund.amountAmount of bonuses (according to the currency used) an existing billing user can receive as a bonus upon each refill of the account balance.
Percentage from the payment an existing billing user can receive as a bonus upon each refill of the account balance.
Amount of bonuses (according to the currency used) the destroyed/deactivated billing user can receive upon refilling of the account balance (and thus reactivating the account).
Percentage from the payment the destroyed/deactivated billing user can receive as a bonus upon refiling of the account balance (and thus reactivating the account).
Amount of bonuses (according to the currency used) a user can receive for the first payment done after the account conversion (can be 0).
A number of days after sign up when the reward system for converting the newly registered trial account ends.
Percentage from the first payment made after the account conversion, that can be received by a user as a bonus (can be 0).
A number of days after sign up when the reward system for converting the newly registered trial account starts.
The bandwidth of a container for performing the disk input/output operations. Note that this quota value is applied during container creation, so changing it won’t affect the already existing containers.
10485760 B = 10 MB
The maximum number of disk input/output operations that a container is allowed to perform per second. Note that this quota value is applied during container creation, so changing it won’t affect the already existing containers.
|operations per second||100||100||100|
The maximum available HDD space per container. Note that this quota value is applied during container creation, so changing it won’t affect the already existing containers.
Enabling the Docker® standard support for users.
The maximum allowed amount of endpoint connections for a single node.
Enabling the Endpoints feature availability for users.
Enabling the Environment Export/Import option availability for users.
Allowing users to attach an External IP address to their containers.
Allowing users to use the High Availability option.
The maximum amount of cloudlets that can be allocated for each container.
The maximum amount of environments, allowed to be created by one user.
The maximum overall amount of nodes, allowed to be added to a single environment.
The maximum amount of the same-type nodes, allowed to be added within a single environment.
Allowing the environment migration between regions.
Enabling the firewall for the newly created end-user's containers. State 1/0 as a value to enable/disable this quota respectively.
The maximum amount of data (per container) that is allowed to be transmitted during the fixed amount of time. Note that this quota value is applied during container creation, so changing it won’t affect the already existing containers.
Enabling/disabling sending of the built-in Jelastic notifications regarding the billing-related events (like the necessity of account upgrade, its deactivation or destroying, receiving bonus funds for conversion).
This quota defines if users are permitted to access their environments via SSH. State 1/0 as a value to enable/disable this quota respectively.
Giving opportunity for users to attach the internal IP address to a VPS node and remove the usually obligatory external one. Set 1/0 as a value to enable/disable this quota respectively.
Note: It is strongly recommended not to enable the vds.internal.ip.enabled quota for all users as this is rather unsecure. With an internal IP attached to a VPS node, a user gets an opportunity to operate with an internal platform network, scan it, know the number and type of servers, etc. Thus you should enable this quota only for separate users upon the particular request received and at your own risk.
Enabling the .NET/Windows hosting support for users.