Qoddi automatically builds your Rust apps created from the platform.
In order to do that, Qoddi uses buildpacks to detect and build your app automatically.
Before Building your app
Qoddi requires several files to be placed inside the root directory of your app to be able to build it :
Procfilewith the command that should be executed to run your app.
The Cargo configuration can be altered using Environment variables added directly to your app :
|Additional arguments for
cargo install. By default, the buildpack will run
cargo install --color=never --root=<destination layer> --path=<path-to-member> for each workspace member.
|A comma delimited list of the workspace package names (this is the package name in the member’s
Cargo.toml, not what is in the workspace’s
Cargo.toml‘s member list) to install. If the project is not using workspaces, this is not used. By default, for projects with a workspace, the buildpack will build all members in a workspace. See more details below.
|Colon separated list of glob patterns to match source files. Any matched file will be retained in the final image. Defaults to
|Colon separated list of glob patterns to match source files. Any matched file will be specifically removed from the final image. If include patterns are also specified, then they are applied first and exclude patterns can be used to further reduce the fileset.
tini to launch binary targets. Defaults to
tini is installed and used by default. Set to
tini will not be installed or used.
|Disable running the SBOM scanner. Defaults to
false, so the scan runs. With larger projects this can take time and disabling the scan will speed up builds. You may want to disable this scane when building locally for a bit of a faster build, but you should not disable this in CI/CD pipelines or when you generate your production images.
|Additional tools that should be installed by running
cargo install. This should be a space separated list, and each item should contain the name of the tool to install like
diesel_cli. Tools installed will be installed prior to compiling application source code and will be available on
$PATH during build execution (but are not installed into the runtime container).
|Any additional arguments to pass to
cargo install when installing
BP_CARGO_INSTALL_TOOLS. The same list is passed through to every tool in the list. For example,
Additional arguments for
cargo install. Any additional arguments specified, are specified for each invocation of
cargo install. The buildpack will execute
cargo install once for each workspace member. If you’re not using a workspace, then it executes a single time.
A few examples of what you can specify:
--path=./todoto build a single member in a folder called
./todoif you have a non-traditional folder structure
--binsto build all binaries in your project
--bin=footo specifically build the foo binary when multiple binaries are present
-vto get more verbose output from
--lockedor customizing how Cargo will use the Cargo.lock file
--offlinefor preventing Cargo from trying to access the Internet
- or any other valid arguments that can be passed to
You may not set
--color and you may not set
--root. These are fixed by the buildpack in order to make output look correct and to ensure that binaries are installed into the proper location.
This option may be used in conjunction with
BP_CARGO_INSTALL_ARGS, however you may not set
BP_CARGO_INSTALL_ARGS when also setting
BP_CARGO_WORKSPACE_MEMBERS, as the buildpack will control
--path when building workspace members.
--pathto build one specific member of a workspace.
BP_CARGO_INSTALL_ARGSto specify non-
BP_CARGO_WORKSPACE_MEMBERSto specify one or more workspace members to build (using
BP_CARGO_WORKSPACE_MEMBERSwith only one member has identical behavior to
- Don’t set either
BP_CARGO_WORKSPACE_MEMBERSand the buildpack will iterate through and build all of the members in workspace.
Rustup is enabled by default
$BP_RUSTUP_ENABLED environment variable must be
true (see below)
The buildpack will do the following:
rustup-initto a layer marked
cachewith command on
rustup-initwith the output written to a layer marked
cachewith installed commands on
rustupto install a Rust toolchain to a layer marked
cachewith installed commands on
|Configure rustup to be enabled. This means that rustup will be used to install Rust. Default value is
true. Set to false to use another Rust toolchain provider like rust-dist (see below).
|Rust toolchain to install. Default
stable. Other common values:
nightly or a specific versin number. Any acceptable value for a toolchain can be used here.
|Rust profile to install. Default
minimum. Other acceptable values:
complete. See Rustup docs for profile.
|Configure the version of rustup-init to install. It can be a specific version or a wildcard like
1.*. It defaults to the latest
|Configure the libc implementation used by the installed toolchain. Available options:
musl. Defaults to
gnu for compatiblity.
Using Rust-dist instead of Rustup
The Rust Dist Cloud Native Buildpack provides a Rust toolchain from a zip archive distribution.
The buildpack installs the Rust toolchain onto the
$PATH which makes it available for the builder to use.
Set the below environment variable to use Rust-dist :
|As a user of the buildpack, you may specify which version of Rust gets installed by setting this environment variable at build time. The version you specify must exist in the
buildpack.toml file or you will get an error.
rust-dist buildpack optionally accepts the following bindings:
|If needed, the buildpack will fetch the dependency with digest
A default Procfile uses only the web argument :
web: ROCKET_PORT=$PORT ROCKET_KEEP_ALIVE=0 /workspace/bin/<project>
To uses more than one argument, just add more lines to
One of the lines needs to be named
web, which is the expected name for the default process.
/workspace is where your application files live.
Apps are compiled into a binary, the builder doesn’t propagate the application source into the final container.
That leaves you with
/workspace/bin/<your-binaries> as a folder structure. This is the path that must be used inside the Procfile
Debug and Access Logs
The log page inside your App settings only provides limited logs and is erased after each app reboot or rebuild.
Launch a Console Command
Please check this article on how to launch a command directly to your running app. This can be used to perform database migrations, launch local scripts, or perform database backups.
Contrary to Marketplace apps that can use Qoddi’s virtual disks features to store and retrieve persistent data, apps that are created from code use an immutable file system.
You can write data locally, for instance, to process files temporarily during your application life, but the data written into your app’s disk is not persistent and gets wiped out after your app restart.
All apps restart at least once every 24 hours, to apply a new setting or to deploy a new build.
To store data and keep it persistent you can use external services like Amazon S3 or Wasabi, an S3 compatible storage service with very affordable pricing.
Define environment variables
Note: Environment variables set in your app settings are injected during the build process. If the build of your app needs to use an env variable make sure to set it before requesting the build.
Qoddi lets you externalize the configuration of your app: the Qoddi cluster will automatically inject the data when the app starts or restart.
Environment variables can include any external data your app needs to run like external resources, databases addresses, encryption keys, etc…
To add an environment variable, access your app settings and click “Add ENV Variable” :
Enter the key (like DATABASE_USER) and the value and click “Add”. Qoddi will automatically add your environment variable and restart your app after a one-minute delay (to let you add more env variables if necessary without restarting the app each time a new variable is added).
Add a domain name
Please check this article for a detailed method on how to use your domain name with Qoddi’s apps.
Provision a database
Qoddi’s Marketplace includes all popular datastore engines including Mysql, Postgres, MongoDB, and Redis.
To add a database to your app, click on Marketplace and select the database you want to run, then create the new app database inside the same stack as your Rust app.
Once the app is running, visit the database app’s settings and retrieve the “internal name” :
Use this internal name as you would use a server address, for instance for MySQL this name replaces the usual “localhost”. Some scripts require you to add the database port at the end of the server address. Qoddi uses a common port for each database software, for MySQL it will be 3306 and you can write it like that inside your scripts: internal-name:3306
Postgres usually uses credentials sent inside the login URL, like that : postgres://<user>:<password>@<internalname>:5432/<database>
The login and password information is available inside the Environment Variables of the database app.
Note: Qoddi’s datastores run on a private and encrypted network. Therefore SSL support is deactivated for all datastores available on Qoddi. Ensure that your code doesn’t require using SSL before deploying your app.
Reach your app from another app
Inside your app stack, you can reach any other Qoddi app member of this stack on any port. Qoddi automatically routes the traffic internally and opens the appropriate port. By opposition, your app is only reachable on ports 80/443 from outside of Qoddi.
To reach your app internally, retrieve the internal name from your app settings page :
This name can be used to reach your app from another app inside the same stack. Use it in any form that works with your script :
Note: https:// is not available, all the traffic inside apps is already encrypted by the cluster.
Qoddi uses at rest encryption for the app virtual disks, build images, and encrypted transport from inside the cluster. To make sure the traffic is encrypted between your app and the browser of your users you can set up SSL certificates for any domain name connected to the app (including the Qoddi’s default domain name).
Scale your App
From your app settings you can scale your app vertically and horizontally: by upgrading the app size (refer to our pricing for app sizes details) or by adding more nodes.
Additional nodes will run another copy of your app inside another Qoddi server located inside the same cluster (same geographical location). Traffic is automatically sent to the least occupied node by Qoddi’s load balancer.
Was this helpful?
2 / 2