You need to enable JavaScript to run this app.
Volcano Engine Function as a Service

Volcano Engine Function as a Service

Copy page
Download PDF
Native runtime
Development guidelines (for tasks)
Copy page
Download PDF
Development guidelines (for tasks)
In veFaaS, tasks are one-off scripts that run asynchronously in non-WebServer mode after a request is submitted. This topic describes the specifications and development guidelines for tasks.​
Service specifications​
When developing a task, follow the specifications below:​
  • Startup command​
  • By default, a task is executed using the startup command configured in the function settings. You can specify a custom startup command when you submit a task.​
  • After completing local development, configure the default startup command when you create a task in the console.​
  • After the service is released successfully, you can specify a custom startup command when you submit the task.​
  • If the start process is relatively complex, we recommend providing a startup script in the project.​
  • Listening port​
  • A task runs in non-WebServer mode, so the service does not need to listen on a port. You need only to specify the command or task script to run via the startup command.​
  • Database/Storage mounting​
  • veFaaS itself is stateless, and a service startup does not rely on local memory cache or disk-persisted data. To maintain state, store data in remote Redis or MySQL databases, or mount remote storage such as FileNAS or TOS (see Mounting FileNAS and Mounting TOS for details).​
  • Disk limits​
  • The maximum writable temporary storage space (the /tmp directory) for a task instance is 512 MiB. Exceeding this limit may trigger instance eviction. If larger storage is needed, ensure disk usage stays within bounds or implement custom file cleanup/rotation logic.​
Task script example​
For complex tasks, provide a startup script in your project and configure the startup command to invoke it. A simple task script example is shown below:​
​
#!/bin/bash # ​
​
# Set strict error handling options as needed:​
# -E: Make ERR trap effective in functions and subshells.​
# -e: Exit the script when a command returns non-zero status.​
# -u: Treat undefined variables as errors.​
# -o pipefail: Return non-zero status if any command in the pipeline fails.​
set -Eeuo pipefail​
​
# Switch the working directory to the directory where the script is located.​
cd "$(dirname "$0")"​
​
# Log the task start time.​
echo "Script started at $(date)"​
​
# List contents of the current directory.​
ls​
​
# Simulate a simple task: sleep 10s.​
echo "Simulating task: Sleeping for 10 seconds"​
sleep 10​
​
# Log the task end time.​
echo "Script done at $(date)"​
​
warning​
The startup script must have the appropriate execute permission. Otherwise, the task will fail with a permission denied error. You can refer to the following command to grant execute permission to the script for all user groups in a Linux system.​
​
chmod a+x run.sh​
​
warning​
When deploying a function using a custom image, ensure that the provided image includes the required shell. Skip shell preparation for deployment using a code package, as the veFaaS-provided image includes sh and bash shell interpreters by default.​
​
# Run the following command in a custom image container to view the shells supported by the current system​
cat /etc/shells​
​
# After running the command above, the terminal displays output similar to the following, which is the list of shells available in your image:​
/bin/sh​
/bin/bash​
/bin/rbash​
/bin/dash​
​
​
Last updated: 2026.08.19 14:06:05