V (Vlang) application runtime
Overview
V is a very simple modern language, similar to Go. It’s a statically typed compiled programming language designed for building maintainable software. Its design has also been influenced by Oberon, Rust, Swift, Kotlin, and Python. One of its forces is it comes with a strong standard library, built-in modules and a package manager. Thus, it includes a web server easy to use in V applications : Veb.
V (Vlang) is a new runtime
Help us to improve it by reporting any issue or suggestion on the Clever Cloud Community
Create your V (Vlang) application
To create a new V (Vlang) application, use the Clever Cloud Console or Clever Tools:
clever create --type vConfigure your V (Vlang) application
Mandatory needs
V (Vlang) runtime only requires a working application listening on 0.0.0.0:8080.
Dependencies
If a v.mod file exists at the root of your project, dependencies are installed with v install before compilation. Modules are stored in the VMODULES directory (default: /home/bas/.vmodules/) and cached between deployments.
Build phase
During the build phase, the V (Vlang) application is built with the v . -prod command. To compile without the -prod flag, set ENVIRONMENT=development. You can choose a custom output binary name with the CC_V_BINARY environment variable, default is ${APP_HOME}/v_bin_${APP_ID}.
Custom run command
By default, the compiled binary is executed directly. To override this behavior, set CC_RUN_COMMAND.
V (Vlang) version and tools
The currently deployed version of V (Vlang) on Clever Cloud is 0.5.
V scripts (.vsh), Clever Tasks
V (Vlang) can be used to execute shell scripts (.vsh). On Clever Cloud, to run such workloads as Clever Tasks, configure an application as Tasks from the Information panel in the Console or with Clever Tools:
clever create --type v --task "./your-script.vsh --and arguments"
clever deploy # or clever restart if there is no code changeEnable health check during deployment
The healthcheck allows you to limit downtimes. Indeed, you can provide Clever Cloud with paths to check. If these paths return something other than 200, the deployment will fail.
Add one (or several) environment variable as such:
CC_HEALTH_CHECK_PATH=/my/awesome/pathOr
CC_HEALTH_CHECK_PATH_0=/my/awesome/path
CC_HEALTH_CHECK_PATH_1=/my/other/pathThe deployment process checks all paths. All of them must reply with a 200 OK response code.
By default, when no environment variable (for ex: APP_HOME) is defined, the monitoring checks your repository root path /.
Example
Using the path listed above, below are the expected logs:
Response from GET /my/awesome/path is 200
Response from GET /my/other/path is 500
Health check failed:
- GET /my/other/path returned 500.
If the deployment fails after this message, please update your configuration and redeploy.In this example, the first path is OK, but the second one failed. This gives you a hint on what failed in your application.
Best practice for healthcheck endpoints
To make the most of a healthcheck endpoint, have it check your critical dependencies. For example:
- execute
SELECT 1 + 1;on your database - retrieve a specific Cellar file
- ping a specific IP through a VPN
Request Flow: Varnish, Redirection.io, custom proxy
Request Flow automatically chains reverse proxies between port 8080 (public) and your application, managing port allocation with no manual configuration. Supported services are activated by their presence in your project:
- Varnish: add a
clevercloud/varnish.vclfile or setCC_VARNISH_FILE - Redirection.io: set
CC_REDIRECTIONIO_PROJECT_KEY
Both can be active simultaneously. To control the order, set CC_REQUEST_FLOW (e.g. redirectionio,varnish). To add a custom middleware, include custom in the chain and define CC_REQUEST_FLOW_CUSTOM with @@LISTEN_PORT@@ and @@FORWARD_PORT@@ placeholders. To block public access, set CC_REQUEST_FLOW=block.
When at least one middleware is active, your application must listen on port 9000 instead of 8080.
Did this documentation help you ?