FAQ

We want to give our customers the information they need to get the most from our STACKIT Cloud Foundry service. This FAQ section answers common questions. This helps you quickly find solutions and improve your experience. We encourage you to check these FAQ before contacting our support team, as you might find your answer here.

• General information

  Expand all

  My service is not working, where can I get help?

  Create an incident in the STACKIT Help Center.

  How do I change the quota of my organization?

  Create a service request in the STACKIT Help Center.

  I have a questions that is not answered in the documentation.

  Feel free to create a service request in the STACKIT Help Center.

• Apps

  Expand all

  What are the limitations for apps on STACKIT Cloud Foundry?

  Individual app process instances and tasks limitations can be found on the page Requirements for applications.

  How to quickly roll back to the last working app container, when a new push fails?

  If your app does not work after pushing and there is no time to adapt or to push an older version, e.g. because external dependencies or the buildpack changed, you can always revert to the last working container build, which is called droplet (uploaded app code is saved as a package that is used to build the droplet with the buildpack):

  cf droplets [APP_NAME] # look out for the droplet GUID from the last successful build

  cf set-droplet [APP_NAME] [DROPLET_GUID] # directly exchanges the container images

  How to use an older builpack version or another community buildpack from GitHub with a specific tag?

  You may specify any specific Cloud Foundry community buildpack with its official GitHub URL and version tag like this:

  https://github.com/cloudfoundry/java-buildpack.git#v4.61.0

  You can list all current, supported, built-in buildpacks with the cf buildpacks CLI command.

  Please note that you should use that for temporary cases as it is not recommended to use outdated buildpacks. You get full STACKIT Cloud Foundry support with the built-in buildpacks only.

  The staging of my app fails while downloading dependencies. How to fix that?

  The staging of the app fails while downloading dependencies with “error: 400, Bad Request” or “error: 405 Forbidden” or “read udp …: i/o timeout” or “read: connection reset by peer” (or similar).

  The standard Cloud Foundry buildpacks are not cached and they need to download dependencies from the Internet during the application staging process. If these dependencies are not available, the application staging fails. For such scenarios we also offer locally available, offline buildpacks - these cached buildpacks include all necessary dependencies, ensuring that the application staging process can complete successfully without needing to download anything from the Internet. For more details please refer to the How-to Use offline buildpacks.

• Deprecated components

  Expand all

  Why does my Java Spring Boot app push fail recently?

  Please watch out when updating existing Spring Boot Java apps from March 2024 on, because the deprecated Spring Cloud Connector and Spring Auto Reconfiguration have been removed in favour of the java-cfenv library with Spring Boot Version 3. Older Spring Boot versions are not affected.

  Why does my customized buildpack app push fail recently?

  For all apps it is recommended to use the latest buildpack versions provided with the platform, as older community buildpacks may use outdated container base images. An example of an outdated container base image is the linuxfs3 stack, which will be removed from the platform from April 2024 on.

  Deprecation of Cloud Foundry Stack cflinuxfs3 and Migration to cflinuxfs4

  Please watch out when updating existing Spring Boot Java apps from March 2024 on, because the deprecated Spring Cloud Connector and Spring Auto Reconfiguration have been removed in favour of the java-cfenv library with Spring Boot Version 3. Older Spring Boot versions are not affected.

  STACKIT Cloud Foundry runtime uses stacks, a prebuilt root file system that in combination with application code and buildpacks is the base to build the application container. The stack in the STACKIT Cloud Foundry environment is based on a Linux system and is called cflinuxfs[x].

  Stacks receive regular updates to address security issues and vulnerabilities, which your applications can pick up through new releases and version updates of the STACKIT Cloud Foundry Runtime.

  Currently in the STACKIT Cloud Foundry environment, some applications still run on a stack called cflinuxfs3, which is based on Ubuntu Bionic Beaver 18.04. This stack was deprecated in December 2022 and is planned to be removed from STACKIT Cloud Foundry environment in June 2024. This change affects anyone who is running buildpack-based applications in STACKIT Cloud Foundry environment.

  The successor stack cflinuxfs4, based on Ubuntu Jammy Jellyfish 22.04, is currently the default stack in STACKIT Cloud Foundry environment. This means that all new applications will use this stack automatically.

  Existing applications running on cflinuxfs3 stack will not be affected by this change, but it is recommended that you update them to use the new stack by following the guide below. The old stack will be removed after June 2024 and your app can stop working if it is not compatible with the cflinuxfs4 stack.

  To maintain functionality and compliance with security standards in STACKIT Cloud Foundry environment, you must migrate your applications to cflinuxfs4. We recommend that you start testing your applications with the new stack as soon as possible to be able to fix potential issues.

  How to change to cflinuxfs4

  To start using cflinuxfs4 with existing applications, you can push the application and designate the stack manually using:

  cf push [APP_NAME] -s cflinuxfs4

  Or you can also adjust the stack in the app manifest. For reference check the Cloud Foundry docs.

  Fallback to cflinuxfs3

  You can continue to use cflinuxfs3 for a transitionary period. This means you can also manually switch back to cflinuxfs3 if you notice problems using the new stack by using the “-s” command when pushing your application:

  cf push [APP_NAME] -s cflinuxfs3

  cflinuxfs3 will be permanently deleted after June 2024. Afterwards it is no longer possible to manually switch back to cflinuxfs3. For more information on stacks, see the Cloud Foundry docs.

  Find out your current stack

  Using the CF CLI

  If you are unsure which stack your applications are currently running on, you can determine it by using the CF CLI. Run the command:

  cf app [APP_NAME]

  The resulting output displays information about the application you specified. The output also includes a line starting with “stack:” followed by the name of the stack currently in use.

  If cflinuxfs3 is shown here, your application is still using the deprecated stack. If cflinuxfs4 is listed, your application is already using the new stack and no further action is required.

  Using the Stack auditor plugin

  The CF CLI supports the use of third-party plugins. To check which stacks your applications are using, you can use the Stack Auditor CLI Plugin to list applications for each org that you have access to. For more information, see the stack auditor docs.

  Using jq

  Alternatively, you can use the jq tool and the CF CLI to query the CF APIs for this information.

  Using the jq tool, you can run the following script to get an overview of the stack and buildpacks used for all applications within a Cloud Foundry org:

  cf curl "/v3/apps?per_page=5000&include=space.organization" | jq '(.included.spaces | INDEX(.guid)) as $spaces | (.included.organizations | INDEX(.guid)) as $orgs | [ .resources[] | {app: .name, org:$orgs[$spaces[.relationships.space.data.guid].relationships.organization.data.guid].name ,space: $spaces[.relationships.space.data.guid].name , lifecycle} ]'

  If you want to filter for cflinuxfs3 to display the applications that require manual migration, use:

  cf curl "/v3/apps?per_page=5000&include=space.organization" | jq '(.included.spaces | INDEX(.guid)) as $spaces | (.included.organizations | INDEX(.guid)) as $orgs | [ .resources[] | select(.lifecycle.data.stack == "cflinuxfs3") | {app: .name, org:$orgs[$spaces[.relationships.space.data.guid].relationships.organization.data.guid].name ,space: $spaces[.relationships.space.data.guid].name , lifecycle} ]'

  Check before migration

  To check that your application is working properly on the new stack, we recommend that you test it before proceeding with the migration. To do so, push your application a separate time using a new name and a separate route by running:

  cf push [APP_NAME] -s cflinuxfs4

  If your applications use or contain any precompiled binaries, it is possible that you need to recompile them. An example of this are applications depending on binary libraries such as OpenSSL or Python, where cflinuxfs4 relies on newer versions than the ones provided by cflinuxfs3.

  If everything worked well, you can continue with your productive apps and change their stack by simply defining it in the cf push command or in the Cloud Foundry manifest. To avoid an unwanted reversion to cflinuxfs3, ensure that your Continuous Deployment automation deploys your applications with cflinuxfs4 as well.

  Risks and Consequences

  If the applications were running, the restart causes a short downtime.

  If you’re using the blue-green deployment method to push your applications, they are automatically deployed on cflinuxfs4. This only works if you delete the unused blue or green applications. For more information see the Cloud Foundry docs on blue-green deployment.

  You can also use the rolling app deployment method to update your applications with zero downtime. For more information see the Cloud Foundry docs on rolling deployment. However, if your applications are incompatible with the cflinuxfs4 stack, it is possible that they stop working and cannot be restarted.

  Migration of Spring Cloud Connectors and Spring Auto Reconfiguration to java-cfenv

  With the release of the Java buildpack v4.49, the Spring Cloud Connectors & Spring Auto Reconfiguration were deprecated. The purpose of these components was to inject credentials from service bindings into Spring apps. It has been deprecated in favour of the java-cfenv library.

  With buildpack version v4.51 and v4.52 the deprecated library was disabled by default but could be re-enabled by setting the following environment variables:

  JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '{enabled: true}'

  Version v4.62 (released in Sep 2023) replaces the deprecated Auto Reconfiguration library with the new java-cfenv library only for Spring Boot 3 applications. Spring Boot 2 applications will receive the deprecated library until Spring Boot 2 is end-of-life on August 24th 2025. Java Buildpack v4.62 is part of our platform release since March 2024.

  See more on migrating to java-cfenv.

  Is your app affected?

  • Only apps that use the Java buildpack >v4.61 are affected.

  • No java-cfenv library already added to the app as a user-dependency

  • All Spring Boot apps with version >= 3 that actively use one of the following dependencies are affected:

    • org.springframework.boot:spring-boot-starter-cloud-connectors
    • org.springframework.cloud:spring-cloud-core
    • org.springframework.cloud:spring-cloud-connectors-core
    • org.springframework.cloud:spring-cloud-cloudfoundry-connector
    • org.springframeworkcloud:spring-cloud-spring-service-connector
    • org.cloudfoundry:java-buildpack-auto-reconfiguration

  Affected apps stop working properly after setting the following env:

  via CLI

  cf set-env <APP> JBP_CONFIG_SPRING_AUTO_RECONFIGURATION '{enabled: false}'

  or in manifest.yml under env:

    JBP_CONFIG_SPRING_AUTO_RECONFIGURATION: '{enabled: false}'

  • These are e.g. apps that expect the cloud profile to be set automatically by Spring.
  • These are also apps that access the cf env not through vcap.foo.etc but through cloud.foo.etc.

  What do you need to do?

  This varies from app to app. For some apps it will be enough to change a few dependencies in pom.xmlor build.gradle. For other apps it will be necessary to set a more explicit instantiation of the client for the respective service. The following points will help with orientation.

  Revert to the last container build (droplet)

  If your app does not work after pushing and there is no time to adapt or to quickly specify the previous java buildpack version described in the following, you always can revert to the last working container build, which is called droplet (uploaded app code is saved as a package that is used to build the droplet with the buildpack):

  cf droplets <APP_NAME> # look out for the droplet GUID from the last successful build

  cf set-droplet <APP_NAME> <DROPLET_GUID>

  Temporary use of the previous java buildpack v4.61.0

  You may specify any specific Cloud Foundry community buildpack with its official GitHub URL and version tag like this:

  https://github.com/cloudfoundry/java-buildpack.git#v4.61.0

  You can list all currently supported built-in buildpacks with the cf buildpacks CLI command.

  Please note that you should use that for temporary cases only as it is not recommended to use outdated buildpacks. You get full STACKIT Cloud Foundry support with the built-in buildpacks only.

  java-cf-env

  One of the most important steps is to remove the affected dependencies and add a new one:

  implementation 'io.pivotal.cfenv:java-cfenv-boot:2.4.0'

  You can find the documentation of the library on github.

  We also recommended this Spring article (please use the current version of the library).

  This allows you to use the usual syntax in application.yml to access the cf env, for example:

  ${vcap.services.myservice.credentials.etc:#{"default_value"}}

  It is also still possible to access the cf env via the @Value annotation (although the approach via the application.yml is preferable as best practice).

  @Value("${vcap.services.myservice.credentials.password}") private String
  password;

  In addition, the library provides a set of EnvironmentPostProcessors to mimic the function of the Cloud Connectors as much as possible (see Using Spring Boot). These include processors to the following service types:

  • RabbitMQ (AMQP only, no Stomp or MQTT)
  • Redis

  Spring Cloud Profile

  Spring Auto Reconfiguration has set the cloud profile for the app.

  If the profile is still needed, it can still be set via the CF CLI or manifest:

  via CLI

  cf set-env <APP> SPRING_PROFILES_ACTIVE cloud

  or in manifest.yml under env:

  env:
    SPRING_PROFILES_ACTIVE: cloud

• Access

  Expand all

  Why is SSH access to my app not working?

  Make sure you are using one of the documented ways to access your app via cf CLI or native SSH command. Access via web UI console is not supported. After April 2024 SSH access to apps will be disabled by default for newly deployed apps. It can be re-enabled with: cf enable-ssh [APP_NAME]. For more details check the official open source Cloud Foundry documentation.

  My service account (technical user id) shows an outdated expiry date in the credentials section, but it still works - is this an issue?

  In 2023 the automated credential expiration was disabled for service account or technical user credentials upon several customer requests. Previously created credentials still show this expiryDate field as it is saved alongside the credentials and cannot be removed, unless the credentials get rotated like this documentation Do a password rotation shows.

  Can we use the client IP address in the "X-Forwarded-For" HTTP header to control access?

  We strongly advise against using the “X-Forwarded-For” HTTP header for anything security-related. We provide an alternative; the “STACKIT-CF-Trusted-IP” HTTP header. It contains the client IP address as seen by our load balancer.

  Keep in mind; the IP address contained in the “STACKIT-CF-Trusted-IP” may or may not be the client IP address you expect. An example for that could be the IP address of the last proxy server in front of our load balancer.

• Web UI console

  Expand all

  Is the web UI fully supported?

  The web UI console with its limitations is not supported by the STACKIT Cloud Foundry team and may eventually be discontinued in favour of integrations into the STACKIT Portal and the STACKI APIs. Please check the FAQs above for alternative access to your app logs or app container access via SSH, if you encounter any issues with the web UI.

  I'm trying to deploy an app from a local folder or from GitHub/GitLab but it fails.

  Trying to deploy an app from a local folder or from GitHub/GitLab but it fails with: Failed to deploy app! Reason: Failed due to !

  This is a known issue and there’s no definitive time frame for a fix. In the meantime please use the Cloud Foundry CLI’s “cf push” command.