[Looking for feedback] simplifying IAC framework usage with Lifecycle jobs

Hello there!

Today Qovery lets you deploy any external resources with IAC frameworks like Terraform, Cloudformation, Serverless etc… via the Lifecycle job service type (more info here)

We are working on simplifying this flow, trying to provide a smooth but flexible experience to manage most of the edge cases.

The idea in a few words

We will provide a default configuration to run your IAC scripts. We will still use the lifecycle job in the background but we will provide you with a few default values for Dockerfile, actions and resources. You will still be able to customize the default behaviour in the settings once the service is created.

More in details…

Let’s take this example: deploy an RDS database with Cloudformation

Note: The approach is pretty much the same with other IAC tools like Terraform, serverless etc…

Creation flow

We will ask you 3 things:

  • the repository containing the Cloudformation template
  • the input required by your Cloudformation template (parameters). We won’t support by default to pass parameters one by one, you will have to store all of them in a single file.
  • some environment variables necessary to execute the Cloudformation template (AWS creds, region, name of the template to execute)

:eyes: :eyes: You can find here a prototype of the creation flow

In the background, Qovery will instantiate for you a Lifecycle job with a default value for:

  • Dockerfile (stored on the Qovery control plane).
Below the default Dockerfile that we will use. As you can see, the Cloudformation commands are defined in the Dockerfile and we have provided all the functions to retrieve the Cloudformation output. FROM alpine:3.20.0

set -e
apk update
apk add dumb-init
apk add ‘aws-cli>2.16’ --repository=Index of /alpine/edge/community/
apk add jq
adduser -D app
mkdir /data
chown -R app:app /data

USER app

RUN cat < entrypoint.sh

if [ “$JOB_INPUT” != ‘’ ]

CMD=$1; shift
set -ex

cd cloudformation


case “$CMD” in
echo ‘start command invoked’
aws cloudformation deploy --stack-name $STACK_NAME --template $CF_TEMPLATE_NAME --parameter-overrides $PARAMETERS
echo ‘generating stack output - injecting it as Qovery environment variable for downstream usage’
aws cloudformation describe-stacks --stack-name $STACK_NAME --output json --query ““Stacks[0].Outputs”” > /data/output.json
jq ‘. | { (.OutputKey): { “value”: .OutputValue, “type” : “string”, “sensitive”: false } }’ /data/output.json > /qovery-output/qovery-output.json

echo ‘stop command invoked’
exit 0

echo ‘delete command invoked’
aws cloudformation delete-stack --stack-name $STACK_NAME
aws cloudformation wait stack-delete-complete --stack-name $STACK_NAME

echo ‘raw command invoked’
aws cloudformation “$1” “$2” “$3” “$4” “$5” “$6” “$7” “$8” “$9”

echo ‘debug command invoked. sleeping for 9999999sec’
echo ‘Use remote shell to connect and execute commands’
sleep 9999999999
exit 1

echo “Command not handled by entrypoint.sh: ‘$CMD’”
exit 1


COPY --chown=app:app . cloudformation

set -e
chmod +x entrypoint.sh
cd cloudformation

ENV CF_TEMPLATE_NAME=must-be-set-as-env-var
ENV AWS_REGION = must-be-set-as-env-var
ENV AWS_SECRET_ACCESS_KEY = must-be-set-as-env-var
ENV AWS_ACCESS_KEY_ID = must-be-set-as-env-var

ENTRYPOINT [“/usr/bin/dumb-init”, “-v”, “–”, “/data/entrypoint.sh”]
CMD [“start”]

  • Actions (which Cloudformation run at Start/stop/delete of the environment)
Here the actions that we will use. Note that the real Cloudformation command is defined in the Dockerfile. - Start: CMD=["start"] - Stop: CMD=["stop"] - Delete: CMD=["delete"]
  • Resources (CPU/RAM necessary to run your cloudformation job)


You will find the same settings you have in the existing Lifecycle Job but you will also see a Dockerfile section where you will be able to modify the Dockerfile that was automatically assigned by Qovery.

Need your feedback

What do you think about this new flow?
Do you think we have missed anything?

Feel free to comment or contact me if you want to discuss more about it!