The strategy used for leasing machines. ### Options - PER_LICENSE: Machine processes are counted per-license, i.e. collectively across all of a license's machines. - PER_USER: Machines are counted per-user, per-license. For example, with a max machines value of 2, each user could have 2 machines per-license.
The strategy used for leasing machine processes. ### Options - PER_MACHINE: Processes are counted per-machine. For example, given a policy with a max processes value of 5, each license could have up to 5 processes for each machine. This is the default. - PER_LICENSE: Processes are counted per-license. For example, with a max processes value of 5, each license could have up to 5 processes combined across all machines. - PER_USER: Processes are counted per-user, per-license. For example, with a max processes value of 5, each user could have up to 5 processes combined across all owned machines per-license.
The cryptographic encryption/signature scheme used on the license's key. Can be used to implement offline licensing by securely storing arbitrary data within a license's key.
The license's status, for filtering purposes and to ascertain overall status at-a-glance. An active license is a license that has been created, validated, checked out, or checked in within the last 90 days. An expiring license is a license that is expiring within the next 3 days. One of: ACTIVE, INACTIVE, EXPIRING, EXPIRED, SUSPENDED, or BANNED.
The strategy used for authenticating as a license, for client-side integrations. ### Options - TOKEN: Allow licenses to authenticate using a license token. This is the default. - LICENSE: Allow licenses to authenticate using a license key. - MIXED: Allow both license token and license key authentication (each covered above). - NONE: Disable the ability for licenses to authenticate with the API.
One of day, week, month or year. The frequency at which a license should check-in. ### Options - day: Require a license implementing the policy to check-in at least once every day to remain valid. - week: Require a license implementing the policy to check-in at least once every week to remain valid. - month: Require a license implementing the policy to check-in at least once every month to remain valid. - year: Require a license implementing the policy to check-in at least once every year to remain valid.
The strategy for expired licenses during a license validation and when accessing releases. ### Options - RESTRICT_ACCESS: Expired licenses can continue to access releases published prior to their expiry, but automatic upgrades are disabled. Validation scopes take precedence over expiry check during license validation. - REVOKE_ACCESS: Expired licenses are no longer able to access any releases, including past releases and upgrades. Expiry check takes precedence over scopes during license validation. - MAINTAIN_ACCESS: Expired licenses can continue to access releases published prior to their expiry, but automatic upgrades are disabled. Validation scopes take precedence over expiry check during license validation. In addition, validations with an EXPIRED code will return valid=true. - ALLOW_ACCESS: Expired licenses can access any releases, including past releases and future automatic upgrades. Validation scopes take precedence over expiry check during license validation. In addition, validations with an EXPIRED code will return valid=true.
Control when a machine's initial heartbeat is started. By default, a machine's heartbeat is started on creation when its policy requires a heartbeat. Otherwise, it is started on first ping. ### Options - FROM_CREATION: The heartbeat duration is calculated from the machine's creation time. - FROM_FIRST_PING: The heartbeat duration is calculated from the machine's first heartbeat ping.
The strategy used for culling dead machines and processes. ### Options - DEACTIVATE_DEAD: Automatically deactivate machines that fail to maintain their heartbeat pings. This is the default. - KEEP_DEAD: Mark machines that fail to maintain their heartbeat pings as dead, but do not deactivate.
The strategy used for controlling whether or not dead machines and processes can be resurrected shortly after death. A resurrection occurs when a heartbeat ping is sent to a dead machine or process that is within its resurrection window. ### Options - NO_REVIVE: Do not allow dead machines and processes to be revived. This is the default. - 1_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 1 minute from its time of death. - 2_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 2 minutes from its time of death. - 5_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 5 minutes from its time of death. - 10_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 10 minutes from its time of death. - 15_MINUTE_REVIVE: A machine or process can be revived if it sends a ping within 15 minutes from its time of death. - ALWAYS_REVIVE: A machine or process can always be revived. Requires a cull strategy of KEEP_DEAD.
The strategy used for leasing machines. ### Options - PER_LICENSE: Machine processes are counted per-license, i.e. collectively across all of a license's machines. - PER_USER: Machines are counted per-user, per-license. For example, with a max machines value of 2, each user could have 2 machines per-license.
The matching strategy for machine fingerprints supplied during a license validation. ### Options - MATCH_ANY: At least 1 of the supplied fingerprints must match a fingerprint for the license's associated machines. E.g. if 3 fingerprints are supplied, at least 1 of them must match. - MATCH_TWO: At least 2 of the supplied fingerprints must match a fingerprint for the license's associated machines. E.g. if 4 fingerprints are supplied, at least 2 of them must match. - MATCH_MOST: The majority of supplied fingerprints must match the fingerprints for the license's associated machines. E.g. if 3 fingerprints are supplied, at least 2 of them must match. - MATCH_ALL: All supplied fingerprints must match the fingerprints for the license's associated machines. E.g. if 3 fingerprints are supplied, all 3 of them must match.
The matching strategy for machine fingerprints supplied during a license validation. ### Options - UNIQUE_PER_ACCOUNT: Machine fingerprints must be unique across the entire Keygen account. This will block all duplicate fingerprints, regardless of whether or not the fingerprint belongs to another product, policy or license. - UNIQUE_PER_PRODUCT: Machine fingerprints must be unique across all licenses belonging to a product. This will block all duplicate fingerprints of the same product, regardless of whether or not the fingerprint belongs to another policy or license. - UNIQUE_PER_POLICY: Machine fingerprints must be unique across all licenses for the policy. This will block all duplicate fingerprints of the same policy, regardless of whether or not the fingerprint belongs to another license. - UNIQUE_PER_LICENSE: Machine fingerprints must be unique to the license. This will block all duplicate fingerprints for same license, but the same fingerprint can exist across different licenses. This is the default.
The strategy used for allowing machine, core and process overages. Set to NO_OVERAGE to disable overages altogether (attempts to exceed a limit will then result in an error). ### Options - ALWAYS_ALLOW_OVERAGE: The license may exceed its limits, and doing so will not effect the licenses validity, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. - ALLOW_1_25X_OVERAGE: The license may exceed its limits, up to a maximum of 1.25x. Exceeding a limit will not effect the license's validity right away, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. The license will begin to fail validation once the 1.25x allowance has been exceeded. When using a 1.25x allowance, all resource limits must be divisible by 4. - ALLOW_1_5X_OVERAGE: The license may exceed its limits, up to a maximum of 1.5x. Exceeding a limit will not effect the license's validity right away, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. The license will begin to fail validation once the 1.5x allowance has been exceeded. When using a 1.5x allowance, all resource limits must be divisible by 2. - ALLOW_2X_OVERAGE: The license may exceed its limits, up to a maximum of 2x. Exceeding a limit will not effect the license's validity right away, i.e. the following validation codes will return valid=true: TOO_MANY_MACHINES, TOO_MANY_CORES, TOO_MANY_PROCESSES. The license will begin to fail validation once the 2x allowance has been exceeded. - NO_OVERAGE: Do not allow overages. Attempts to exceed limits will fail. This is the default.
The strategy used for leasing machine processes. ### Options - PER_MACHINE: Processes are counted per-machine. For example, given a policy with a max processes value of 5, each license could have up to 5 processes for each machine. This is the default. - PER_LICENSE: Processes are counted per-license. For example, with a max processes value of 5, each license could have up to 5 processes combined across all machines. - PER_USER: Processes are counted per-user, per-license. For example, with a max processes value of 5, each user could have up to 5 processes combined across all owned machines per-license.
The cryptographic encryption/signature scheme used on license keys. Can be used to implement offline licensing by storing tamper-proof data within a license's key. When null or omitted, the license's key will be stored unchanged. ### Options - ED25519_SIGN: Sign license keys with your account's Ed25519 signing key, using elliptic curve cryptography and SHA512. The given license key data will be base64url encoded and then prefixed with key/ before signing, and the signing data's signature will be base64url encoded and then appended onto the end of the signing data, delimited by the . character, e.g. key/{URLBASE64URL_KEY}.{URLBASE64URL_SIGNATURE}. This is our recommended signing scheme, but it may not be supported in your preferred programming language. - **RSA_2048_PKCS1_PSS_SIGN_V2**: Sign license keys with your account's 2048-bit RSA private key using RSA PKCS1-PSS padding, with a SHA256 digest, max salt length, and a SHA256 MGF1. The provided embedded dataset will be base64url encoded and then prefixed with key/ before signing, and the signing data's signature will be base64url encoded and then appended onto the end of the signing data, delimited by the . character, e.g. key/{URLBASE64URL_KEY}.{URLBASE64URL_SIGNATURE}, resulting in the final key. This is our recommended RSA scheme, but it may not be supported in your preferred programming language. - **RSA_2048_PKCS1_SIGN_V2**: Sign license keys with your account's 2048-bit RSA private key using RSA PKCS1 v1.5 padding, with a SHA256 digest. The provided embedded dataset will be base64url encoded and then prefixed with key/ before signing, and the signing data's signature will be base64url encoded and then appended onto the end of the signing data, delimited by the . character, e.g. key/{URLBASE64URL_KEY}.{URLBASE64URL_SIGNATURE}, resulting in the final key. - **RSA_2048_PKCS1_ENCRYPT**: Encrypt license keys with your account's 2048-bit RSA private key using RSA PKCS1 v1.5 padding. The provided dataset will be encrypted using your account's private key and then base64url encoded, resulting in the final key. The key can be decrypted using your account's public key. The key must contain no more than 245 bytes (please note this is byte length not string length). - **RSA_2048_JWT_RS256**: Encode a license claims payload into a JWT using the RS256 algorithm. The license key must be a valid JWT claims payload (i.e. a JSON encoded string). The JWT will be signed using your account's 2048-bit RSA private key and can be verified using your account's public key. The resulting key will be a full JSON Web Token. We do not modify your claims payload.
Control whether a license's expiration is reset when transferred to this policy. ### Options - RESET_EXPIRY: Reset the transferred license's expiry from the time of transfer. For example, if the license had an expiry 3 months from now, and the new policy has a duration of 1 year, transferring would reset the expiry to 1 year from the time of transfer. When the policy has no duration, the license's expiry is removed. - KEEP_EXPIRY: Do not change the license's current expiry. This is the default.
The strategy for distributing releases. ### Options - LICENSED: Only licensed users, with a valid license, can access releases and release artifacts. API authentication is required. - OPEN: Anybody can access releases. No API authentication required, so this is a great option for rendering releases on a public downloads page, open source projects, or freemium products. - CLOSED: Only admins can access releases. Download links will need to be generated server-side. API authentication is required.
The strategy used for leasing machines. ### Options - PER_LICENSE: Machine processes are counted per-license, i.e. collectively across all of a license's machines. - PER_USER: Machines are counted per-user, per-license. For example, with a max machines value of 2, each user could have 2 machines per-license.
The strategy used for leasing machine processes. ### Options - PER_MACHINE: Processes are counted per-machine. For example, given a policy with a max processes value of 5, each license could have up to 5 processes for each machine. This is the default. - PER_LICENSE: Processes are counted per-license. For example, with a max processes value of 5, each license could have up to 5 processes combined across all machines. - PER_USER: Processes are counted per-user, per-license. For example, with a max processes value of 5, each user could have up to 5 processes combined across all owned machines per-license.
The role for the user. ### Options - user: A normal user of one or more of your products. Depending on account settings, they can have permission to manage their own resources, e.g. licenses and machines. They cannot manage other users' resources. - support-agent: An internal administrative user of your Keygen account, with a limited subset of permissions. Support Agents can read most resource data, but cannot create, update or delete resources. - sales-agent: An internal administrative user of your Keygen account, with a limited subset of permissions. Sales Agents can read most resource data, but can only create, update and delete specific resources. - developer: An internal administrative user of your Keygen account, with permission to manage all resources, but they cannot manage account billing. - read-only: An internal administrative user of your Keygen account, with permission to read all resources, except for account billing. - admin: An internal administrative user of your Keygen account, with permission to manage the entire account.
The user's status, for filtering purposes and to ascertain overall status at-a-glance. An active user is a user that was created within the last 90 days, or has a license that has been created, validated, checked out, or checked in within the last 90 days. An inactive user is a user that has none of those traits. One of: ACTIVE, INACTIVE, or BANNED.
