Engines are automatically populated by the current packages and their
releases. The below endpoints are read-only. To activate an engine,
create a package implementing the desired engine e.g. pypi, npm,
rubygems, etc.
An authentication token with privileges to read the release engine: either an admin, the product it belongs to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated engines.
A 200 OK response will be returned along with an engine object.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
An authentication token with privileges to read the engines: either an admin, the product the releases belong to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated engines.
A 200 OK response will be returned along with a list of engine objects.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
An authentication token with privileges to read the releases: either an admin, the product it belongs to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated releases.
A 200 OK response will be returned along with an HTML document containing
links to the package artifacts, in accordance with PEP 503.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
Install a package that implements the pypi engine using pip. Only
packages that implement the pypi engine will be available for
install. Packages for other engines, or packages without an
engine, will not be available.
In addition, only packages which are available to the current requestor
will be included, e.g. if you don't authenticate then only OPEN
packages will be included.
Please prefer --index-url over --extra-index-url, for security reasons.
Because pip does not lock dependencies to specific repositories, and because
pip provides no protection from package spoofing, we recommend using Keygen
as the sole package index. All non-Keygen packages will be securely
redirected to PyPI for fulfillment (also known as a "pass through"
PyPI repository).
This prevents pip from installing a package with the same name from PyPI
instead of Keygen, preventing a supply chain attack vector.
Alternatively, you can add the --index-url flag to your requirements.txt.
Alternatively, you can configure the engine globally via pypi.conf. This will
make pip install all packages through Keygen. Keygen is a pass-through
PyPI repository, meaning we will redirect all non-Keygen packages to PyPI.
Please see earlier security notice on --index-url vs --extra-index-url.
Alternatively, you can configure the engine globally via .pypirc.
Notes on publishing
Please note that we DO NOT support uploading Python packages via twine.
To upload a new version of a package, you can run python setup.py bdist_wheel sdist
and then use the CLI or the UI to draft a new package release,
then upload your whl and other distribution artifacts.
An authentication token with privileges to read the releases: either an admin, the product it belongs to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated releases.
The version constraint for the upgrade. For example, constraint=1.0 will constrain all upgrades to version 1.x, while constraint=1.0.0 will constrain to version 1.0.x. This is useful if a given license is only entitled to a specific version range. Major version is required.
You can also use constraints to constrain to a specific prerelease tag, such as constraint=1-beta, or to a specific build tag like constraint=1%2Bfoo (note the URL-encoded + symbol).
The release channel. One of: stable, rc, beta, alpha or dev. The rc channel will include stable releases. The beta channel will include rc and stable. Alpha will include beta, rc, and stable. Dev will only include releases on the dev channel (you can think of it as 'nightly' or 'edge', i.e. following a master branch).
A 200 OK response will be returned along with the update object.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
You can use Keygen with Tauri's native updater
to implement auto-updates for your Tauri app. Releases can be drafted
and artifacts uploaded via the CLI or UI.
Please note that signatures MUST be explicitly set on uploaded artifacts.
We do not automatically read accompanying .sig artifacts.
Using the CLI, this would look something like this:
An authentication token with privileges to read the artifacts: either an admin, the product it belongs to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated releases.
A 303 See Other redirect will be returned, pointing to the artifact's canonical URL.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
An authentication token with privileges to read the releases: either an admin, the product it belongs to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated releases.
A 200 OK response will be returned along with a gem index in plaintext format.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
Install a package that implements the Rubygems engine using bundler or
gem. Only packages that implement the rubygems engine will be available
for install. Packages for other engines, or packages without an engine,
will not be available.
In addition, only packages which are available to the current requestor
will be included, e.g. if you don't authenticate then only OPEN
packages will be included.
Notes on publishing
Please note that we DO NOT support pushing Ruby gems via gem push.
To upload a new version of a gem, you can run gem build and then use
the CLI or the UI to draft a new package release, then
upload your gem artifacts.
When installing gems, the source method must be used to instruct Rubygems to install
from an alternative source. You may provide authentication in the source directly,
or you can define the credentials globally via .gemrc, which will let bundler
and gem install gems without having to hard-code authentication into the
source definition.
An authentication token with privileges to read the releases: either an admin, the product it belongs to, an entitled license (via license key or a license token), or a user with an entitled license. If there are products with an OPEN distribution strategy, no authentication is required to read their associated releases.
A 200 OK response will be returned along with the package metadata in JSON format.
Upon error, an errors object will be returned along with an
HTTP status code indicating the type of error. When an error occurs, the
data property will not be included.
Install a package that implements the npm engine using npm. Only packages that
implement the npm engine will be available for install. Packages for other
engines, or packages without an engine, will not be available. In addition,
only packages which are available to the current requestor will be included,
e.g. if you don't authenticate then only OPEN packages will be included.
For most use-cases, you'll be most successful using scoped packages, since it's
a lot easier to instruct npm to install all packages under @your-scope from a
private registry vs an unscoped package. In addition, we always recommend obtaining
the same scope on npm's public registry as well — otherwise a similarly named
package on the public npm registry may be installed instead of your package.
When installing packages via package.json, the easiest way to instruct npm to install
from your private registry is to use a package scope configured to point to a particular
registry — otherwise a similarly named package on the public npm registry may be
installed instead of your package.
You can instruct npm to install packages under a particular scope from a private
registry using an .npmrc file, or by configuring the registry via npm config.
Whether or not to use .npmrc vs npm config is a personal preference.
For authentication, you have a couple options:
You can set a license key using the :username and :_password parameters,
where :username is license and :_password is a base64-encoded license
key (note the value for :_password MUST be base64-encoded).
You can set an API token via the :_authToken= parameter.
Whether or to use license keys vs tokens is a personal preference.
Notes on publishing
Please note that we DO NOT support pushing npm packages via npm push.
To upload a new version of a package, you can run npm pack and then use
the CLI or the UI to draft a new package release, then
upload your tgz tarball artifact.