- Without a source integration - With a source integration In your local copy of your repository, create a new environment from `old` called `main`: `upsun environment:branch main old`In your local copy of the external repository, make sure your default branch is up to date: `git checkout old && git pull origin old` Then create the `main` branch off of your default branch and push it to the remote repository: ``` git checkout -b main git push origin main ``` Source integrations include all branches, but don’t activate the corresponding environments in Upsun. Activate the `main` environment by running the following command: `upsun environment:activate main` ## 2. Copy settings If you have variables or other settings specific to your default environment, add those to the `main` environment. For example, you may have variables for your production environment set to not be inheritable (such as if you set them with `--inheritable=false` through the CLI). These variables aren't added automatically to child environments and so you need to add them to the `main` environment manually. If you want the `main` environment to send emails, [turn on outgoing email](https://docs.upsun.com/development/email.md). ## 3. Make `main` a top-level branch To have `main` be your default, it needs to not be a child of `old`. Use the following command to remove its parent and make it a top-level branch: ```bash upsun environment:info -e main parent - ``` ## 4. Make `main` the parent for other environments

- Without a source integration - With a source integration You probably have other environments that are children of `old`. For each environment, update its parent to `main`: `upsun environment:info -e parent main`To preserve your data on Upsun, it’s best to switch your work in progress to be based off of `main`. Close any open pull/merge requests and resubmit them against `main`. If you want to continue working on branches after switching the default branch, rebase them by running `git rebase --onto main `. Once you resubmit a request, it appears under the `main` environment on Upsun. ## 5. Deactivate the `old` branch To change your default branch, you first need to deactivate the existing default branch to remove protections. Deactivate the `old` environment without deleting it by running the following CLI command: ```bash upsun environment:delete --no-delete-branch old ``` ## 6. Set `main` as the default branch

- Without a source integration - With a source integration Once `old` has been deactivated, set the project’s default branch to `main`: `upsun project:info default_branch main`Set the project’s default branch in Upsun to `main`: `upsun project:info default_branch main` Follow the instructions to change the default branch to `main` for your provider: - [GitHub](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/changing-the-default-branch) - [GitLab](https://docs.gitlab.com/ee/user/project/repository/branches/default.html#change-the-default-branch-name-for-a-project) - [BitBucket](https://community.atlassian.com/t5/Bitbucket-questions/How-to-change-MAIN-branch-in-BitBucket/qaq-p/977418) ## 7. Update DNS records Whether or not you're using a CDN, if your site is live you have probably added a Upsun address somewhere when configuring a [custom domain](https://docs.upsun.com/domains/steps.md). If you have a CDN, it's with the CDN provider. If you don't have a CDN, it's probably a `CNAME` record. In either case, the setting probably has the old environment name as part of it. Update the setting to use the new environment name. Verify that the new URL is correct by comparing it to the result from this command: ```bash upsun environment:info edge_hostname ``` ## 8. Optional: Delete the `old` environment If you no longer want the `old` environment, such as to stop accidental use, delete it completely: ```bash upsun environment:delete --delete-branch old ``` # Resolve access issues with source integrations If you [add a user](https://docs.upsun.com/administration/users.md#add-a-user-to-a-project) to a Upsun project, but you haven’t added them to the remote repository on GitHub, GitLab, or Bitbucket, they can't clone the project locally. That user might try to clone the repository using the CLI with the following command: ```bash upsun get PROJECT_ID ``` In this case, the user gets an error similar to the following: ```txt Failed to connect to the Git repository: git@github.com:organization/repository.git Please make sure you have the correct access rights and the repository exists. ``` ## Solution: Check external repository access rights To enable the user to clone the repository, grant them the correct access rights for the integrated repository. # Rewrite requests without redirects You might want to rewrite requests so they're served by specific sections of your app without having to redirect users. For example, you might want to make URLs seem semantic to users without having to rewrite your app architecture. In such a case, you might want requests to `/shoes/great-shoe/` to be served as if they were requests to `/?category=shoes&product=great-shoe`. If so, add a [rule](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#rules) similar to the following: ```yaml {configFile="app"} applications: myapp: source: root: "/" web: locations: '/': ... rules: '^/(?[^/]+)/(?[^/]+)/$': passthru: '/?category=$category&product=$product' ``` Or you might organize your images by file type, but don't want to expose the organization externally. You could rewrite requests to do that behind the scenes: ```yaml {configFile="app"} applications: myapp: source: root: "/" web: locations: '/': ... rules: '^/img/(?.*)\.(?.*)$': passthru: '/$type/$name.$type' ``` Now a request to `/img/image.png` returns the file found at `/png/image.png`. ## Query parameters Query parameters in the request are unaffected and are passed in the request to the app. So if you have the category and product rule from previously, a request to `/shoes/great-shoe/?product=terrible-shoe` is rewritten to `?category=shoes&product=great-shoe&product=terrible-shoe`. In that case, the `product` query parameter returns as `terrible-shoe`. # Ruby ### Note You can now use composable image (BETA) to install runtimes and tools in your application container. To find out more, see the [dedicated documentation page](https://docs.upsun.com/create-apps/app-reference/composable-image.html). Upsun supports deploying any Ruby application. Your application can use any Ruby application server such as Puma or Unicorn and deploying a Rails or a Sinatra app is very straight forward. ## Supported versions You can select the major and minor version. Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest available patches. ### Ruby MRI - 3.3 - 3.2 - 3.1 - 3.0 ### Specify the language To use Ruby, specify `ruby` as your [app's `type`](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.html#types): ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. : type: 'ruby:' ``` For example: ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ``` ### Deprecated versions The following versions are [deprecated](https://docs.upsun.com/glossary.html#deprecated-versions). They're available, but they aren't receiving security updates from upstream and aren't guaranteed to work. They'll be removed in the future, so migrate to one of the supported versions. - 2.7 - 2.6 - 2.5 - 2.4 - 2.3 ## Puma based Rails configuration This example uses Puma to run a Ruby application. You could use any Ruby application server such as Unicorn. Configure the `.upsun/config.yaml` file with a few key settings as listed below. A complete example is included at the end of this section. 1. Specify the language of your application (available versions are listed above): ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ``` 2. Setup environment variables. Rails runs by default on a preview environment. You can change the Rails/Bundler via those environment variables, some of which are defaults on Upsun. ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' variables: env: PIDFILE: "tmp/server.pid" # Allow to start puma directly even if `tmp/pids` directory is not created RAILS_ENV: "production" BUNDLE_WITHOUT: 'development:test' TARGET_RUBY_VERSION: '~>3.3' # this will allow to not fail on PATCH update of the image ``` The `SECRET_KEY_BASE` variable is generated automatically based on the [`PLATFORM_PROJECT_ENTROPY` variable](https://docs.upsun.com/development/variables/use-variables.md#use-provided-variables) but you can change it. Based on TARGET_RUBY_VERSION, we recommand to set on your Gemfile so next PATCH release of ruby doesn't fail the build: ```ruby ruby ENV["TARGET_RUBY_VERSION"] || File.read(File.join(File.dirname(__FILE__), ".ruby-version")).strip ``` 3. Build your application with the build hook. Assuming you have your dependencies stored in the `Gemfile` at [your app root](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#root-directory), create a hook like the following: ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ... hooks: build: | set -e bundle install bundle exec rails assets:precompile deploy: bundle exec rake db:migrate ``` These are installed as your project dependencies in your environment. You can also use the `dependencies` key to install global dependencies. These can be Ruby, Python, NodeJS, or PHP libraries. If you have assets, it's likely that you need NodeJS/yarn. ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ... dependencies: nodejs: yarn: "*" ``` 4. Configure the command to start serving your application (this must be a foreground-running process) under the `web` section: ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ... web: upstream: socket_family: unix commands: # for puma start: "bundle exec puma -b unix://$SOCKET" # for unicorn # start: "bundle exec unicorn -l $SOCKET" ``` This assumes you have Puma as a dependency in your Gemfile: ```ruby gem "puma", ">= 5.0" ``` 5. Define the web locations your application is using: ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ... web: locations: "/": root: "public" passthru: true expires: 1h allow: true ``` This configuration sets the web server to handle HTTP requests at `/static` to serve static files stored in `/app/static/` folder. Everything else is forwarded to your application server. 6. Create any Read/Write mounts. The root file system is read only. You must explicitly describe writable mounts. ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: type: 'ruby:3.3' ... mounts: "/log": source: tmp source_path: log "/storage": source: storage source_path: storage "/tmp": source: tmp source_path: tmp ``` This setting allows your application writing temporary files to `/app/tmp`, logs stored in `/app/log`, and active storage in `/app/storage`. You can define other read/write mounts (your application code itself being deployed to a read-only file system). Note that the file system is persistent and when you backup your cluster these mounts are also backed up. 7. Then, setup the routes to your application in `.upsun/config.yaml`. ```yaml {configFile="app"} applications: ... routes: "https://{default}/": type: upstream upstream: "myapp:http" ``` ### Complete app configuration Here is a complete `.upsun/config.yaml` file: ```yaml {configFile="app"} # The name of the app, which must be unique within a project. applications: myapp: type: 'ruby:3.3' dependencies: nodejs: yarn: "*" relationships: mysql: variables: env: BUNDLE_CACHE_ALL: '1' # Default, Cache all gems, including path and git gems. BUNDLE_CLEAN: '1' # /!\ if you are working with Ruby<2.7 this doesn't work well, but should be safe on modern Rubies. BUNDLE_DEPLOYMENT: '1' # Default, Disallow changes to the Gemfile. BUNDLE_ERROR_ON_STDERR: '1' # Default. BUNDLE_WITHOUT: 'development:test' PIDFILE: "tmp/server.pid" # Allow to start puma directly even if `tmp/pids` directory is not created DEFAULT_BUNDLER_VERSION: "2.5.14" # In case none is mentioned in Gemfile.lock EXECJS_RUNTIME: 'Node' # If you need one on your assets https://github.com/rails/execjs#readme NODE_ENV: 'production' NODE_VERSION: v14.17.6 NVM_VERSION: v0.38.0 RACK_ENV: 'production' RAILS_ENV: 'production' RAILS_LOG_TO_STDOUT: '1' # Default RAILS_TMP: '/tmp' # Default hooks: build: | set -e echo "Installing NVM $NVM_VERSION" unset NPM_CONFIG_PREFIX export NVM_DIR="$PLATFORM_APP_DIR/.nvm" # install.sh will automatically install NodeJS based on the presence of $NODE_VERSION curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/$NVM_VERSION/install.sh | bash [ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # we install the bundled bundler version and fallback to a default (in env vars above) export BUNDLER_VERSION="$(grep -A 1 "BUNDLED WITH" Gemfile.lock | tail -n 1)" || $DEFAULT_BUNDLER_VERSION echo "Install bundler $BUNDLER_VERSION" gem install --no-document bundler -v $BUNDLER_VERSION echo "Installing gems" # We copy the bundle directory to the Upsun cache directory for # safe keeping, then restore from there on the next build. That allows # bundler to skip downloading code it doesn't need to. [ -d "$PLATFORM_CACHE_DIR/bundle" ] && \ rsync -az --delete "$PLATFORM_CACHE_DIR/bundle/" vendor/bundle/ mkdir -p "$PLATFORM_CACHE_DIR/bundle" bundle install # synchronize updated cache for next build [ -d "vendor/bundle" ] && \ rsync -az --delete vendor/bundle/ "$PLATFORM_CACHE_DIR/bundle/" # precompile assets echo "Precompiling assets" # We copy the webpacker directory to the Upsun cache directory for # safe keeping, then restore from there on the next build. That allows # bundler to skip downloading code it doesn't need to. # https://guides.rubyonrails.org/asset_pipeline.html mkdir -p "$PLATFORM_CACHE_DIR/webpacker" mkdir -p "$RAILS_TMP/cache/webpacker" [ -d "$PLATFORM_CACHE_DIR/webpacker" ] && \ rsync -az --delete "$PLATFORM_CACHE_DIR/webpacker/" $RAILS_TMP/cache/webpacker/ # We dont need secret here https://github.com/rails/rails/issues/32947 SECRET_KEY_BASE=1 bundle exec rails assets:precompile rsync -az --delete $RAILS_TMP/cache/webpacker/ "$PLATFORM_CACHE_DIR/webpacker/" deploy: bundle exec rake db:migrate mounts: "/log": source: tmp source_path: log "/storage": source: storage source_path: storage "/tmp": source: tmp source_path: tmp web: upstream: socket_family: unix commands: # for puma start: "bundle exec puma -b unix://$SOCKET" # for unicorn # start: "bundle exec unicorn -l $SOCKET" locations: "/": root: "public" passthru: true expires: 1h allow: true routes: "https://{default}/": type: upstream upstream: "myapp:http" services: ... ``` ## Configuring services This example assumes there is a MySQL instance. To configure it, [create a service](https://docs.upsun.com/add-services.md) such as the following: ```yaml {configFile="services"} applications: ... routes: ... services: mysql: type: mysql:11.4 ``` ## Connecting to services Once you have a service, link to it in your [app configuration](../create-apps/_index.md): ```yaml {configFile="app"} applications: myapp: type: 'ruby:3.3' relationships: mysql: [...] routes: [...] services: mysql: type: mysql:11.4 ``` By using the following Ruby function calls, you can obtain the database details. ```ruby require "base64" require "json" relationships= JSON.parse(Base64.decode64(ENV['PLATFORM_RELATIONSHIPS'])) ``` This should give you something like the following: ```json { "mysql" : [ { "path" : "main", "query" : { "is_master" : true }, "port" : 3306, "username" : "user", "password" : "", "host" : "mysql.internal", "ip" : "246.0.241.50", "scheme" : "mysql" } ] } ``` For Rails, you can use the standard Rails `config/database.yml` with the values found with the snippet provided before. ## Other tips - To speed up boot you can use the [Bootsnap gem](https://github.com/Shopify/bootsnap) and configure it with the local `/tmp`: ```ruby {location="config/boot.rb"} Bootsnap.setup(cache_dir: "/tmp/cache") ``` - For garbage collection tuning, you can read [this article](https://shopify.engineering/17489064-tuning-rubys-global-method-cache) and look for [discourse configurations](https://github.com/discourse/discourse_docker/blob/b259c8d38e0f42288fd279c9f9efd3cefbc2c1cb/templates/web.template.yml#L8) - New images are released on a regular basis to apply security patches. To avoid issues when such updates are performed, use ``` ruby ruby ENV["TARGET_RUBY_VERSION"] || File.read(File.join(File.dirname(__FILE__), ".ruby-version")).strip ``` in your `Gemfile`. ## Troubleshooting By default, deployments have `BUNDLE_DEPLOYMENT=1` to ensure projects have a `Gemfile.lock` file. This is safer for version yank issues and other version upgrade breakages. You may encounter an error like the following during a build: ```txt W: bundler: failed to load command: rake (https://docs.upsun.com/app/.global/bin/rake) W: /app/.global/gems/bundler-2.3.5/lib/bundler/resolver.rb:268:in `block in verify_gemfile_dependencies_are_found!': Could not find gem 'rails (= 5.2.6)' in locally installed gems. (Bundler::GemNotFound) ``` To resolve this error: 1. Run `bundle install` with the same `ruby` and `bundler` versions defined in your `.upsun/config.yaml` file. 2. Push the `Gemfile.lock` to your repository. # Rust ### Note You can now use composable image (BETA) to install runtimes and tools in your application container. To find out more, see the [dedicated documentation page](https://docs.upsun.com/create-apps/app-reference/composable-image.html). Upsun supports building and deploying applications written in Rust. ## Supported versions You can select the major version. But the latest compatible minor version is applied automatically and can’t be overridden. Patch versions are applied periodically for bug fixes and the like. When you deploy your app, you always get the latest available patches. - 1 ## Dependencies The recommended way to handle Rust dependencies on Upsun is using Cargo. Commit a `Cargo.toml` and a `Cargo.lock` file in your repository so the system automatically downloads dependencies using Cargo. ## Building and running your app Assuming your `Cargo.toml` and `Cargo.lock` files are present in your repository, you can build your app using the `cargo build` command to produce a working executable. You can then start it from the `web.commands.start` directive. Note that the start command _must_ run in the foreground. If the program terminates for any reason it is automatically restarted. The following basic [app configuration](https://docs.upsun.com/create-apps.md) is sufficient to run most Rust apps. See the complete example below for more details. ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: # The language and version for your app. type: 'rust:1' hooks: build: cargo build web: commands: # Customize the start command with your own target. start: './target/debug/hello' locations: /: # Route all requests to the Rust app, unconditionally. allow: false passthru: true ``` Note that there is still an Nginx proxy server sitting in front of your application. If desired, certain paths may be served directly by Nginx without hitting your application (for static files, primarily) or you may route all requests to the Rust app unconditionally, as in the example above. ## Built-in variables Upsun exposes relationships and other configuration as [environment variables](https://docs.upsun.com/development/variables.md). To get the `PORT` environment variable (the port on which your app is supposed to listen), use the following snippet: ```rust let port : String = env::var("PORT").unwrap_or(String::from("8888")); ``` Note that some of the environment variables are in JSON format and are base64 encoded. For example, to decode the `PLATFORM_RELATIONSHIPS` environment variable, use the following snippet: ```rust use base64::{Engine as _, engine::{general_purpose}}; use serde_json::Value; let bytes = general_purpose::STANDARD.decode(env::var("PLATFORM_RELATIONSHIPS").unwrap_or(String::new())).unwrap(); let psh_config: Value = serde_json::from_slice(&bytes).unwrap(); println!("{}", psh_config["database"]); ``` ## Complete example Here is a basic hello world app to illustrate how you can use Rust with Upsun. It builds from a `hello.rs` file to serve a static `index.html`. Follow these steps: 1. [Install Rust and Cargo](https://www.rust-lang.org/tools/install). 2. Create a repository for your app and add the following `Cargo.toml` file: ```toml [package] name = "hello_world" version = "0.1.0" edition = "2021" [[bin]] name = "hello" path = "hello.rs" [dependencies] time = "0.1.12" regex = "0.1.41" base64 = "0.21.0" serde = { version = "1.0", features = ["derive"] } serde_json = "1.0" ``` 3. Add the following [app configuration](../../create-apps/_index.md): ```yaml {configFile="app"} applications: # The app's name, which must be unique within the project. myapp: # The language and version for your app. type: 'rust:1' hooks: build: cargo build web: commands: # Customize the start command with your own target. start: './target/debug/hello' locations: /: # Route all requests to the Rust app, unconditionally. allow: false passthru: true ``` 4. To generate a `Cargo.lock` file, run the following command: ```bash cargo generate-lockfile ``` 5. Add the following `hello.rs` file: ```rust /* Simple HTTP Server */ /* Author : Ramesh Vyas */ use std::io::prelude::*; use std::net::TcpListener; use std::net::TcpStream; use std::fs; use std::env; fn main() { /* Creating a Local TcpListener at Port 8888 */ const HOST : &str ="127.0.0.1"; let port : String = env::var("PORT").unwrap_or(String::from("8888")); /* Concating Host address and Port to Create Final Endpoint */ let end_point : String = HOST.to_owned() + ":" + &port; /*Creating TCP Listener at our end point */ let listener = TcpListener::bind(end_point).unwrap(); println!("Web server is listening at port {}",port); /* Connecting to any incoming connections */ for stream in listener.incoming() { let _stream = stream.unwrap(); // Call Function to process any incomming connections handle_connection(_stream); } } fn handle_connection(mut stream: TcpStream) { let mut buffer = [0; 1024]; stream.read(&mut buffer).unwrap(); let get = b"GET / HTTP/1.1\r\n"; if buffer.starts_with(get) { let contents = fs::read_to_string("index.html").unwrap(); let response = format!( "HTTP/1.1 200 OK\r\nContent-Length: {}\r\n\r\n{}", contents.len(), contents ); stream.write(response.as_bytes()).unwrap(); stream.flush().unwrap(); } else { // some other request } } ``` # Sanitizing databases: MariaDB and Drupal Databases of live websites often contain personally identifiable information (PII) such as full names, mailing addresses, and phone numbers. To ensure people reviewing code changes can't access information they shouldn't, sanitize your databases of any PII that they may contain. This example goes through the process for a MySQL database using Drupal. ## Before you begin You need: - A project with a [MySQL database](https://docs.upsun.com/add-services/mysql.md). - A command interface installed: - If doing it manually, the [Upsun CLI](https://docs.upsun.com/administration/cli.md). - Otherwise, make sure [Drush](https://www.drush.org/latest/install/) is installed in your environment. This guide is about sanitizing MySQL databases. This guide doesn't address: - Sanitizing NoSQL Databases (such as [MongoDB](https://docs.upsun.com/add-services/mongodb.md)) - Input validation and input sanitization, which both help prevent security vulnerabilities ## Sanitize the database Make sure that you only sanitize preview environments and **never** the production environment. Otherwise you may lose most or even all of the relevant data stored in your database. First, take a [database dump](https://docs.upsun.com/add-services/mysql.md#exporting-data) of your preview environment. This is just a safety precaution. Production data isn't altered. To get a database dump, run the following command: ``` upsun db:dump -e DEVELOPMENT_ENVIRONMENT_NAME ```. - Manually - With Drupal and Drush Assumptions: - `users` is the table where all of your PII is stored in the `staging` development database. - `staging` is an exact copy of your production database. - Connect to the `staging` database by running `upsun sql -e staging`. - Display all fields from your `users` table, to select which ones need to be redacted. Run the following query: ``` MariaDB [main]> SELECT * FROM users; ``` You see output like the following: ``` +----+------------+---------------+---------------------------+---------------+ | ID | first_name | last_name | user_email | display_name | +----+------------+---------------+---------------------------+---------------+ | 1 | admin | admin | admin@yourcompany.com | admin | | 2 | john | doe | john.doe@gmail.com | john | | 3 | jane | doe | janedoe@ymail.com | jane | +----+------------+---------------+---------------------------+---------------+ ``` - Change the fields where PII is contained with the [ statement](https://mariadb.com/kb/en/update/). For example, to change the display name of users with an email address not in your company’s domain to a random value, run the following query: ``` UPDATE users SET display_name==substring(md5(display_name||'$PLATFORM_PROJECT_ENTROPY') for 8); WHERE email NOT LIKE '%@yourcompany%' ``` Adapt and run that query for all fields that you need to sanitize. If you modify fields that you shouldn’t alter, [you can restore them](https://docs.upsun.com/environments/restore.html) from the dump you took in step 1. You can create a script to automate the sanitization process to be run automatically on each new deployment. Once you have a working script, add your script to sanitize the database to [ hook](https://docs.upsun.com/create-apps/hooks/hooks-comparison.html#deploy-hook): ``` applications: myapp: # ... hooks: deploy: | # ... cd /app/public if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ]; then # Do whatever you want on the production site. else # The sanitization of the database should happen here (since it's non-production) sanitize_the_database.sh fi ``` To sanitize your database and get rid of sensitive, live information, use the `drush sql:sanitize` command. Add your script to sanitize the database to [ hook](https://docs.upsun.com/create-apps/hooks/hooks-comparison.html#deploy-hook) for preview environments: ``` applications: myapp: hooks: deploy: | # ... cd /app/public if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ]; then # Do whatever you want on the production site. else drush -y sql:sanitize fi drush -y updatedb ``` More options are available. These are described in the [Drush documentation](https://www.drush.org/latest/commands/sql_sanitize/). To sanitize only on the initial deploy and not all future deploys, use [Drush state](https://www.drush.org/latest/commands/state_set/) as in the following example: ``` applications: myapp: hooks: deploy: | # ... cd /app/public if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ] || [ "$(drush state:get --format=string mymodule.sanitized)" != yes ]; then # Do whatever you want on the production site. else drush -y sql:sanitize drush state:set --input-format=string mymodule.sanitized yes fi ``` ## What's next You learned how to remove sensitive data from a database. To replace sensitive data that with other meaningful data, you can add a `faker` to the process. A `faker` is a program that generates fake data that looks real. Having meaningful PII-free data allows you to keep your current Q&A, external reviews, and other processes. To add a faker, adapt your sanitizing queries to replace each value that contains PII with a new value generated by the faker. You might also want to make sure that you [implement input validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#goals-of-input-validation). If your database contains a lot of data, consider using the [`OPTIMIZE TABLE` statement](https://mariadb.com/kb/en/optimize-table/) to reduce its size and help improve performance. # Sanitizing databases: PostgreSQL and Django Databases of live websites often contain personally identifiable information (PII) such as full names, mailing addresses, and phone numbers. To ensure people reviewing code changes can't access information they shouldn't, sanitize your databases of any PII that they may contain. This example goes through the process for a PostgreSQL database using Django. ## Before you begin You need: - A project with a [PostgreSQL database](https://docs.upsun.com/add-services/postgresql.md). - A command interface installed: - If doing it manually, the [Upsun CLI](https://docs.upsun.com/administration/cli.md). - Otherwise, make sure `pqsl` is installed in your environment. This guide is about sanitizing PostgreSQL databases. This guide doesn't address: - Sanitizing NoSQL Databases (such as [MongoDB](https://docs.upsun.com/add-services/mongodb.md)) - Input validation and input sanitization, which both help prevent security vulnerabilities ## Sanitize the database Make sure that you only sanitize preview environments and **never** the production environment. Otherwise you may lose most or even all of the relevant data stored in your database. First, take a [database dump](https://docs.upsun.com/add-services/postgresql.md#exporting-data) of your preview environment. This is just a safety precaution. Production data isn't altered. To get a database dump, run the following command: ``` upsun db:dump -e DEVELOPMENT_ENVIRONMENT_NAME ```. - Manually - Using a script with Django and `psql` Assumptions: - `users` is the table where all of your PII is stored in the `staging` development database. - `staging` is an exact copy of your production database. - Connect to the `staging` database by running `upsun sql -e staging`. - Display all fields from your `users` table, to select which ones need to be redacted. Run the following query: ``` main=> SELECT * FROM users; ``` You see output like the following: ``` id | user_email | display_name -----+-----------------------------------------+----------------------- 3501 | daniel02@yourcompany.com | Jason Brown 3502 | ismith@kim.com | Sandra Griffin 3503 | olee@coleman-rodriguez.com | Miss Christine Morgan ``` - Change the fields where PII is contained with the [ statement](https://mariadb.com/kb/en/update/). For example, to change the display name of users with an email address not in your company’s domain to a random value, run the following query: ``` UPDATE users SET display_name==substring(md5(display_name||'$PLATFORM_PROJECT_ENTROPY') for 8); WHERE email NOT LIKE '%@yourcompany%' ``` Adapt and run that query for all fields that you need to sanitize. If you modify fields that you shouldn’t alter, [you can restore them](https://docs.upsun.com/environments/restore.html) from the dump you took in step 1. You can create a script to automate the sanitization process to be run automatically on each new deployment. Once you have a working script, add your script to sanitize the database to [ hook](https://docs.upsun.com/create-apps/hooks/hooks-comparison.html#deploy-hook): ``` applications: myapp: # ... hooks: deploy: | # ... cd /app/public if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ]; then # Do whatever you want on the production site. else # The sanitization of the database should happen here (since it's non-production) sanitize_the_database.sh fi ``` Assumptions: - `users` is the table where all of your PII is stored in the `staging` development database. - `database` is the relationship name for the PostgreSQL service. Set up a script by following these steps: - Retrieve service credentials from the [service environment variables](https://docs.upsun.com/development/variables.html#service-environment-variables) to use the `psql` command interface. Export these values to a [ file](https://docs.upsun.com/development/variables/set-variables.html#set-variables-via-script) or include them directly in the sanitization script. ``` # Pull credentials from the service environment variables. DB_USER=${DATABASE_USERNAME} DB_HOST=${DATABASE_HOST} DB_PORT=${DATABASE_PORT} DB_PASS=${DATABASE_PASSWORD} ``` - Create an executable sanitizing script by running the following command: `touch sanitize.sh && chmod +x sanitize.sh` - Make the script sanitize environments with an [environment type](https://docs.upsun.com/administration/users.html#environment-type-roles) other than `production`. The following example runs only in preview environments and sanitizes the `display_name` and `email` columns of the `users` table. Adjust the details to fit your data. sanitize.sh ``` #!/usr/bin/env bash if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ]; then # Sanitize data PGPASSWORD=$DB_PASS psql -c "UPDATE users SET display_name=substring(md5(display_name||'$PLATFORM_PROJECT_ENTROPY') for 8);" -U $DB_USER -h $DB_HOST -p $DB_PORT PGPASSWORD=$DB_PASS psql -c "UPDATE users SET email=substring(md5(email||'$PLATFORM_PROJECT_ENTROPY') for 8);" -U $DB_USER -h $DB_HOST -p $DB_PORT fi ``` To sanitize only on the initial deploy and not all future deploys, on sanitization create a file on a [mount](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.html#mounts). Then add a check for the file as in the following example: sanitize.sh ``` #!/usr/bin/env bash if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ] && [ ! -f MOUNT_PATH/is_sanitized ]; then # Sanitize data touch MOUNT_PATH/is_sanitized fi ``` - Update the deploy hook to run your script on each deploy. ``` applications: myapp: hooks: build: ... deploy: | python manage.py migrate bash sanitize.sh ``` - Commit your changes by running the following command: ``` git add .environment sanitize.sh .upsun/config.yaml&& git commit -m "Add sanitization." ``` Push the changes to `staging` and verify that environment’s database was sanitized. Once merged to production, all data from future preview environments are sanitized on environment creation. ## What's next You learned how to remove sensitive data from a database. To replace sensitive data that with other meaningful data, you can add a `faker` to the process. A `faker` is a program that generates fake data that looks real. Having meaningful PII-free data allows you to keep your current Q&A, external reviews, and other processes. To add a faker, adapt your sanitizing queries to replace each value that contains PII with a new value generated by the faker. You might also want to make sure that you [implement input validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#goals-of-input-validation). If your database contains a lot of data, consider using the [`REINDEX` statement](https://www.postgresql.org/docs/current/sql-reindex.html) to help improve performance. # Sanitizing databases: PostgreSQL and Symfony Databases of live websites often contain personally identifiable information (PII) such as full names, mailing addresses, and phone numbers. To ensure people reviewing code changes can't access information they shouldn't, sanitize your databases of any PII that they may contain. This example goes through the process for a PostgreSQL database using Symfony. ## Before you begin You need: - A project with a [PostgreSQL database](https://docs.upsun.com/add-services/postgresql.md). - A command interface installed: - If doing it manually, the [Symfony CLI](https://symfony.com/download). - Otherwise, make sure `pqsl` is installed in your environment. This guide is about sanitizing PostgreSQL databases. This guide doesn't address: - Sanitizing NoSQL Databases (such as [MongoDB](https://docs.upsun.com/add-services/mongodb.md)) - Input validation and input sanitization, which both help prevent security vulnerabilities ## Sanitize the database Make sure that you only sanitize preview environments and **never** the production environment. Otherwise you may lose most or even all of the relevant data stored in your database. First, take a [database dump](https://docs.upsun.com/add-services/postgresql.md#exporting-data) of your preview environment. This is just a safety precaution. Production data isn't altered. To get a database dump, run the following command: ``` symfony db:dump -e DEVELOPMENT_ENVIRONMENT_NAME ```. - Manually - Using a Symfony Command - Using a shell script Assumptions: - `users` is the table where all of your PII is stored in the `staging` development database. - `staging` is an exact copy of your production database. - Connect to the `staging` database by running `symfony sql -e staging`. - Display all fields from your `users` table, to select which ones need to be redacted. Run the following query: ``` main=> SELECT * FROM users; ``` You see output like the following: ``` id | user_email | display_name -----+-----------------------------------------+----------------------- 3501 | daniel02@yourcompany.com | Jason Brown 3502 | ismith@kim.com | Sandra Griffin 3503 | olee@coleman-rodriguez.com | Miss Christine Morgan ``` - Change the fields where PII is contained with the [ statement](https://mariadb.com/kb/en/update/). For example, to change the display name of users with an email address not in your company’s domain to a random value, run the following query: ``` UPDATE users SET display_name==substring(md5(display_name||'$PLATFORM_PROJECT_ENTROPY') for 8); WHERE email NOT LIKE '%@yourcompany%' ``` Adapt and run that query for all fields that you need to sanitize. If you modify fields that you shouldn’t alter, [you can restore them](https://docs.upsun.com/environments/restore.html) from the dump you took in step 1. You can create a script to automate the sanitization process to be run automatically on each new deployment. Once you have a working script, add your script to sanitize the database to [ hook](https://docs.upsun.com/create-apps/hooks/hooks-comparison.html#deploy-hook): ``` applications: myapp: # ... hooks: deploy: | # ... cd /app/public if [ "$PLATFORM_ENVIRONMENT_TYPE" = production ]; then # Do whatever you want on the production site. else # The sanitization of the database should happen here (since it's non-production) sanitize_the_database.sh fi ``` Assumptions: - An Entity User exist and contains all of your PII (Personally Identifiable Information) - [fakerphp/faker](https://fakerphp.github.io/) has been installed as a dependency on your Symfony application Set up a script by following these steps: - Create a Symfony command to sanitize data src/Command/SanitizeDataCommand.php ``` setDescription('This command allows you to sanitize user data (username and email).'); } protected function execute(InputInterface $input, OutputInterface $output) { $io = new SymfonyStyle($input, $output); $users = $this->userRepository->findAll(); $io->progressStart(count($users)); /** @var User $user */ foreach ($users as $user) { $io->progressAdvance(); // initialize faker $faker = Faker\Factory::create(); // sanitize user info $user->setUsername(uniqid($faker->userName())); $user->setEmail($faker->email()); // adapt to your needs $this->entityManager->flush(); } $io->progressFinish(); return static::SUCCESS; } } ``` - Update the deploy hook to run your Symfony Command on each deploy. ``` applications: myapp: hooks: build: ... deploy: | if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ]; then # The sanitization of the database should happen here (since it's non-production) php bin/console app:sanitize-data fi ``` To sanitize only on the initial deploy and not all future deploys, on sanitization create a file on a mount. Then add a check for the file as in the following example: ``` applications: myapp: hooks: build: ... deploy: | if [ "$PLATFORM_ENVIRONMENT_TYPE" != production ] && [ ! -f MOUNT_PATH/is_sanitized ]; then # The sanitization of the database should happen here (since it's non-production) php bin/console app:sanitize-data touch MOUNT_PATH/is_sanitized fi ``` - Commit your changes by running the following command: ``` git add src/Command/SanitizeDataCommand.php .upsun/config.yaml && git commit -m "Add sanitization." ``` Push the changes to `staging` and verify that environment’s database was sanitized. Once merged to production, all data from future preview environments are sanitized on environment creation. This example show you how to sanitize data on multiple projects inside an organization, except for production environments. Assumptions: - Symfony Command from previous tab `Using a Symfony Command` has already been pushed to all of your environments. Set up a script by following these steps: - Create an executable sanitizing script by running the following command: `touch sanitize_fleet.sh && chmod +x sanitize_fleet.sh` - Make the script sanitize environments with an [environment type](https://docs.upsun.com/administration/users.html#environment-type-roles) other than `production`. The following example runs only in preview environments and sanitizes data using the Symfony Command from previous tab, already pushed to all of your environments. sanitize_fleet.sh ``` if [ -n "$ZSH_VERSION" ]; then emulate -L ksh; fi ###################################################### # fleet sanitization demo script, using the Symfony CLI. # # Enables the following workflow on a project: # . # └── main # ├── staging # | └── new-feature # └── auto-updates # # Usage # 1. source this script: `. sanitize_fleet.sh` or `source sanitize_fleet.sh` depending of your local machine # 2. define ORGANIZATION var: ORGANIZATION= # 3. run `sanitize_organization_data $ORGANIZATION` ###################################################### # Utility functions. # list_org_projects: Print list of projects operation will be applied to before starting. # $1: Organization, as it appears in console.upsun.com. list_org_projects () { symfony project:list -o $1 --columns="ID, Title" } # get_org_projects: Retrieve an array of project IDs for a given organization. # Note: Makes array variable PROJECTS available to subsequent scripts. # $1: Organization, as it appears in console.upsun.com. get_org_projects () { PROJECTS_LIST=$(symfony project:list -o $1 --pipe) PROJECTS=($PROJECTS_LIST) } # get_project_envs: Retrieve an array of envs IDs for a project. # Note: Makes array variable ENVS available to subsequent scripts. # $1: ProjectId, as it appears in console.upsun.com. get_project_envs () { ENV_LIST=$(symfony environment:list -p $1 --pipe) ENVS=($ENV_LIST) } # list_project_envs: Print list of envs operation will be applied to before starting. # $1: ProjectId, as it appears in console.upsun.com. list_project_envs () { symfony environment:list -p $1 } # add_env_var: Add environment level environment variable. # $1: Variable name. # $2: Variable value. # $3: Target project ID. # $4: Target environment ID. add_env_var () { VAR_STATUS=$(symfony project:curl -p $3 /environments/$4/variables/env:$1 | jq '.status') if [ "$VAR_STATUS" != "null" ]; then symfony variable:create \ --name $1 \ --value "$2" \ --prefix env: \ --project $3 \ --environment $4 \ --level environment \ --json false \ --sensitive false \ --visible-build true \ --visible-runtime true \ --enabled true \ --inheritable true \ -q else printf "\nVariable $1 already exists. Skipping." fi } # Main functions. sanitize_organization_data () { list_org_projects $1 get_org_projects $1 for PROJECT in "${PROJECTS[@]}" do printf "\n### Project $PROJECT." # get environments list list_project_envs $PROJECT get_project_envs $PROJECT for ENVIRONMENT in "${ENVS[@]}" do unset -f ENV_CHECK ENV_CHECK=$(symfony project:curl -p $PROJECT /environments/$ENVIRONMENT | jq -r '.status') unset -f ENV_TYPE ENV_TYPE=$(symfony project:curl -p $PROJECT /environments/$ENVIRONMENT | jq -r '.type') if [ "$ENV_CHECK" = active -a "$ENV_TYPE" != production ]; then unset -f DATA_SANITIZED DATA_SANITIZED=$(symfony variable:get -p $PROJECT -e $ENVIRONMENT env:DATA_SANITIZED --property=value) if [ "$DATA_SANITIZED" != true ]; then printf "\nEnvironment $ENVIRONMENT exists and isn't sanitized yet. Sanitizing data." printf "\n" # do sanitization here symfony ssh -p $PROJECT -e $ENVIRONMENT -- php bin/console app:sanitize-data printf "\nSanitizing data is finished, redeploying" add_env_var DATA_SANITIZED true $PROJECT $ENVIRONMENT else printf "\nEnvironment $ENVIRONMENT exists and doesn't need to be sanitized. skipping." fi elif [ "$ENV_TYPE" == production ]; then printf "\nEnvironment $ENVIRONMENT is production one, skipping." else printf "\nEnvironment $ENVIRONMENT isn't active $ENV_CHECK, skipping." fi done done } ``` - use this shell script Depending on the machine you want to run this script on, adapt this to your needs. ``` . sanitize_fleet.sh # or source sanitize_fleet.sh ORGANIZATION= sanitize_organization_data $ORGANIZATION ``` ### Note You can find the organization identifier for a specific project, within the Upsun console, by clicking on your name, and then on “Settings”, in the top right corner. - [Option] Commit your changes by running the following command: ``` git add sanitize_fleet.sh && git commit -m "Add sanitization." ``` Push the changes to `staging` and verify that environment’s database was sanitized. Once merged to production, all data from future preview environments are sanitized on environment creation. ## What's next You learned how to remove sensitive data from a database. To replace sensitive data that with other meaningful data, you can add a `faker` to the process. A `faker` is a program that generates fake data that looks real. Having meaningful PII-free data allows you to keep your current Q&A, external reviews, and other processes. To add a faker, adapt your sanitizing queries to replace each value that contains PII with a new value generated by the faker. You might also want to make sure that you [implement input validation](https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html#goals-of-input-validation). If your database contains a lot of data, consider using the [`REINDEX` statement](https://www.postgresql.org/docs/current/sql-reindex.html) to help improve performance. # Search # Serve directories at different paths In some cases you might want to depart from the common practice of serving directories directly. You might want to create a URL structure different than the structure on your disk. For example, in Git you might have a folder for your app and another folder that builds your documentation. Your entire Git repository might look like the following: ```text .upsun config.yaml application/ [app-code-files] docs-src/ [docs-code-files] ``` And your build process might build the documentation with an output folder such as `docs-public`. If so, you can serve all requests by your app code except for those that start with `/docs`, which you serve with your generated docs. Use a [`web` configuration](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#web) similar to the following: ```yaml {configfile="apps"} applications: docs: source: root: "/" web: locations: '/': passthru: true '/docs': root: 'docs-public' index: - "index.html" expires: 24h scripts: false allow: true ``` This way, your app can safely coexist with static files as if it were a single site hierarchy. And you can keep the static pages separate from your app code. # Serve static sites Static site generators are a popular way to create fast sites. Because there's no need to wait for responses from servers, the sites may load faster. To learn how to serve your static site using Upsun, you can start with the required minimal app configuration and build on it, or jump straight to an example of a complete configuration. ## Minimal app configuration To successfully serve a static site using Upsun, you need to set up a minimal app configuration similar to the following: ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" # The web key configures the web server running in front of your app. web: locations: /: # Static site generators usually output built static files to a specific directory. # Define this directory (must be an actual directory inside the root directory of your app) # as the root for your static site. root: "public" # Files to consider when serving a request for a directory. index: - index.html ``` See more information on the required minimal settings: - [Top-level properties](https://docs.upsun.com/create-apps/app-reference/single-runtime-image#primary-application-properties). - [`web` property](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#web). - [`locations` properties](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#locations). ## Add more features ### Allow static files but not dynamic files on PHP containers If you have a PHP container, you might want to enable client-side scripts but disable server-side scripts. To enable static files that don't match any rule while disabling server-side scripts on a PHP container, use the following configuration: ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: locations: '/': ... scripts: false allow: true ``` See more information on [`locations` properties](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#locations). ### Create cache rules You can create sensible cache rules to improve performance. For example, if you publish new content regularly without updating images or site files much, you might want to cache text files for a day but all image files for longer. To do so, use a configuration similar to the following: ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: locations: '/': ... expires: 24h rules: \.(css|js|gif|jpe?g|png|svg)$: expires: 4w ``` You can also set a `Cache-Control` header in your rules. ```yaml {configFile="app"} applications: myapp: web: locations: '/': ... expires: 24h rules: \.(css|js|gif|jpe?g|png|svg)$: headers: Cache-Control: "public, max-age=2419200, immutable" ``` If `expires` and a `Cache-Control` header are set, the rule ignores the `expires` and sets only the `Cache-Control` header. For this reason, make sure to add a `max-age` value, in seconds, for the `Cache-Control` header. ### Conserve the server Because your site is completely static, it doesn't need the server to be running. To set a background process that blocks the server and conserves resources, use the following configuration: ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: commands: start: sleep infinity ``` You can also use this place to start small programs, such as a [script to handle 404 errors](https://community.platform.sh/t/custom-404-page-for-a-static-website/637). ## Complete example configuration ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "python:3.9" source: root: "/" web: locations: '/': # The public directory of the application relative to its root root: 'public' # The files to look for when serving a directory index: - 'index.html' # Disable server-side scripts scripts: false allow: true # Set caching policy expires: 24h rules: \.(css|js|gif|jpe?g|png|svg)$: expires: 4w commands: # Run a no-op process that uses no CPU resources since this is a static site start: sleep infinity ``` # Set an environment's visibility to search engines When you have preview environments, you don't want search engines indexing them and diluting the SEO of your production site. Search engine indexers are told to ignore all preview environments. When you're ready to go live, give your production environment a [custom domain](https://docs.upsun.com/domains/steps.md) and then set it to be visible to search engines. To change your production environment's visibility to search engines, follow these steps: - Using the CLI - In the Console To not restrict indexers on your production environment, run the following command: `upsun environment:info --environment PRODUCTION_ENVIRONMENT_NAME restrict_robots false` - Select the project where you want to change visibility. - From the **Environment** menu, select your production environment. - Click **Settings**. - In the row with **Hide from search engines**, click **Edit **. - Select or clear the **Hide from search engines** checkbox. Upsun can't guarantee that indexers follow the instructions. If you're concerned about access, set up [HTTP access control](https://docs.upsun.com/environments/http-access-control.md). ## How it's done When the **Hide from search engines** is activated, search engines are turned away from environments by including a `X-Robots-Tag` header: ```txt X-Robots-Tag: noindex, nofollow ``` That tells search engine indexers to not index these sites and not traverse links from these sites. This helps keep non-Production sites out of search engine indexes. It's automatically on for all `upsun.site` domains, and it's automatically off for production environments with a custom domain. ## Alternative method You can also send instructions to search engine indexers using a `robots.txt` file. Your app can serve this as a static file from its disk or as a dynamic response from its `passthru`. Control either with the [`location` section of your app configuration](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#locations). If your `robots.txt` file includes instructions to ignore a page, search engine indexers may ignore it even if you have configured Upsun to not send the header. # Set custom headers on static content When your app responds to dynamic requests, it can generate headers on the fly. To set headers for static content, add them in [your `web` configuration](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#web). You might want to do so to add custom content-type headers, limit what other sites can embed your content, or allow cross origin requests. Say you want to limit most files to be embedded only on your site, but you want an exception for MP3 files. And you want to serve both MP3 and MP4 files with the correct content types to avoid [MIME sniffing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#mime_sniffing). Start by defining a header for files in general: ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: locations: "/": ... # Apply rules to all static files (dynamic files get rules from your app) headers: X-Frame-Options: SAMEORIGIN ``` This sets the `X-Frame-Options` header to `SAMEORIGIN` for all static files. Now your files can only be embedded within your site. Now set up an exception for MP3 files using a [rule](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#rules): ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: locations: "/": ... rules: \.mp3$: headers: Content-Type: audio/mpeg ``` This rule sets an explicit content type for files that end in `.mp3`. Because specific rules override the general heading configuration, MP3 files don't get the `X-Frame-Options` header set before. Now set a rule for MP4 files. ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: locations: "/": ... rules: \.mp4$: headers: X-Frame-Options: SAMEORIGIN Content-Type: video/mp4 ``` This rule sets an explicit content type for files that end in `.mp4`. It repeats the rule for `X-Frame-Options` because the `headers` block here overrides the more general configuration. So now you have three header configurations: * `X-Frame-Options: SAMEORIGIN` **and** `Content-Type: video/mp4` for MP4 files * Only `Content-Type: audio/mpeg` for MP3 files * Only `X-Frame-Options: SAMEORIGIN` for everything else ## Cross origin requests To allow cross origin requests, add a `Access-Control-Allow-Origin` header to responses. You can do so for specific origins or for all origins with a wildcard. ```yaml {configFile="app"} applications: myapp: # The type of the application to build. type: "nodejs:22" source: root: "/" web: locations: "/": ... # Apply rules to all static files (dynamic files get rules from your app) headers: Access-Control-Allow-Origin: "*" ``` If you use the wildcard value, the headers are modified for each request in the following ways: * The value of the `Access-Control-Allow-Origin` header is set to the value of the `Origin` request header. * The `Vary` header is included with a value of `Origin`. See why in the [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#access-control-allow-origin). This is done so that credentialed requests can be supported. They would otherwise fail CORS checks if the wildcard value is used. ## `Strict_Transport_Security` header The `Strict_Transport_Security` header returns a value of `max-age=0` unless you enable [HTTP Strict Transport Security (HSTS)](https://docs.platform.sh/define-routes/https.html#enable-http-strict-transport-security-hsts) in your [routes configuration](https://docs.upsun.com/define-routes.md). Note that once HSTS is enabled, configuration capabilities depend on the [HSTS properties](https://docs.platform.sh/define-routes/https.html#enable-http-strict-transport-security-hsts) set in your routes configuration. For example, the `max-age` value is set to `31536000` by Upsun and can't be customized. # Set variables To set variables, determine which [type of variable](https://docs.upsun.com/development/variables.md#variable-types) to use. Remember to take into account the order of precedence. All of the variables can also be overridden via script. ## Set variables in your app Set variables [in code](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#variables) using the `.upsun/config.yaml` file. These values are the same across all environments and present in the Git repository, which makes them a poor fit for API keys and other such secrets. They're better fits for uses such as configuration for consistent builds across every environment, including setting [PHP configuration values](https://docs.upsun.com/development/variables.md#php-specific-variables). Application variables are available at both build time and runtime. ## Create project variables Add secrets for all environments in project variables using [the Console](https://docs.upsun.com/administration/web/configure-project.md#variables) or the [CLI](https://docs.upsun.com/administration/cli.md). For example, you may need to vary API credentials between production and other environments. To do so, set the non-production credentials as a project variable and then override these credentials for the production environment by setting a variable specific to that environment. - Service environment variables - `PLATFORM_RELATIONSHIPS` environment variable ``` export APP_DATABASE_HOST=${DATABASE_HOST} export APP_DATABASE_USER=${DATABASE_USERNAME} ``` This sets environment variables with the names your app needs, and the values from [service environment variables](https://docs.upsun.com/development/variables.html#service-environment-variables).It uses the `jq` library, which is included in all app containers for this purpose. ``` export APP_DATABASE_HOST=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host") export APP_DATABASE_USER=$(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].username") ``` This sets environment variables with names your app needs, and the values from [ environment variable](https://docs.upsun.com/development/variables/use-variables.html#use-provided-variables). ## Use `.env` files Many applications use a `.env` file in the application root for configuration. These are useful for local development to set variables without needing them to be global across the development computer. Read more about [the use cases for `.env` files](https://platform.sh/blog/2021/we-need-to-talk-about-the-env/). You shouldn't need to use a `.env` file in production. Add it to your `.gitignore` file to avoid confusion as its values can vary for each local developer. # Subscribe to an add-on Depending on your needs, you may want to upgrade to the following Upsun add-ons. You can do so directly from the Console. ## Standard User Management add-on ### Included features The Standard User Management add-on gives you access to the following features: - [Free viewers](https://docs.upsun.com/users.md) - [Organization permissions](https://docs.upsun.com/users.md#organization-permissions) - [Teams](https://docs.upsun.com/administration/teams.md) - [MFA enforcement](https://docs.upsun.com/administration/mfa.md) ### Upgrade to the Standard User Management add-on To upgrade to the Standard User Management add-on, follow these steps: 1. In the Console, navigate to your organization. 2. Open the user menu (your name or profile picture), then select **Billing**. 3. In the **Organization add-ons** section of the **Overview** tab, locate the **User management** panel and click **Upgrade**. 4. In the pop-up window, select **Standard user management** and check the 30-day commitment box. 5. Click **Upgrade**. After the add-on is added to your organization, you can remove it from the same location in the **Overview** tab by clicking **Downgrade**. Once the minimum 30-day commitment period is over, the add-on is removed from your organization and you are no longer billed for it. ## Continuous Profiling add-on ### Included features By default, Upsun offers 15 minutes of continuous profiling per project and for free. When you upgrade to the continuous profiling add-on, you get 30 days of continuous profiling per project for a fixed fee. For more information on incurred costs, see the [Upsun pricing page](https://upsun.com/pricing/). ### Upgrade to the Continuous Profiling add-on To upgrade to this add-on, follow these steps: 1. In the Console, navigate to your organization. 2. Open the user menu (your name or profile picture), then select **Billing**. 3. In the **Overview** tab, find the project on which you want to activate full continuous profiling. 4. Click ** More** next to that project. 5. Click **Project billing**. 3. In the **Project add-ons** section, locate the **Continuous profiling** panel and click **Enable**. 5. To confirm, click **Enable**. # Timezones On Upsun, there are several timezones you might want to keep in mind. All timezones default to UTC time. You can customize some of them, but in most cases, it's best if you leave them in UTC and store user data with an associated timezone instead. The different timezones on Upsun are the following: | Timezone | Description |Customizable | |----------------------|----------------------------------------------|--------------| | Container timezone | The timezone for all Upsun containers (UTC). |No | | App runtime timezone | Set an app runtime timezone if you want your app runtime to use a specific timezone instead of the container timezone.
The app runtime timezone only affects your app itself. | Yes | | Cron timezone | Set a cron timezone.
The cron timezone only affects your cron jobs. | Yes | | Log timezone | The timezone for all Upsun logs (UTC). | No | ### Note Each Upsun project also has a **project timezone** that only affects [automated backups](https://docs.upsun.com/environments/backup.html#automated-backups). By default, the project timezone is based on the [region](https://docs.upsun.com/development/regions.html) where your project is hosted. You can [change it from the Console](https://docs.upsun.com/projects/change-project-timezone.html) at any time. ## Set an app runtime timezone How you can set an app runtime timezone depends on your actual app runtime: - PHP - Node.js - Python - Java Add the following to your app configuration: ``` applications: # The name of the app container. Must be unique within a project. myapp: # The location of the application's code. source: root: "myapp" variables: php: "date.timezone": "Europe/Paris" ```Start the server with `env TZ=’TIMEZONE’ node server.js`.Start the server with `env TZ=’TIMEZONE’ python server.py`. - Start the server with `env TZ=’TIMEZONE’ java -jar …` OR. - Set the Java virtual machine argument `user.timezone`. This Java virtual machine argument takes precedence over the environment variable TZ. For example, you can use the flag `-D` when running the application: `java -jar -D user.timezone=GMT` or `java -jar -D user.timezone="Asia/Kolkata"` ## Set a cron timezone You can set a specific timezone for your crons so they don't run in your app runtime timezone (or container timezone if no app runtime timezone is set on your project). To do so, [set the `timezone` top-level property](https://docs.upsun.com/create-apps/app-reference/single-runtime-image#primary-application-properties) in your app configuration. # Troubleshoot disks For more general information, see how to [troubleshoot development](https://docs.upsun.com/development/troubleshoot). ## Low disk space If you have set up [health notifications](https://docs.upsun.com/integrations/notifications.md), you may receive a notification of low disk space. To solve this issue: * [Check mount usage](https://docs.upsun.com/create-apps/troubleshoot-mounts.md#disk-space-issues) * Check your database disk space * Increase the available disk space ### Check your database disk space To get approximate disk usage for a database, run the command `upsun db:size`. This returns an estimate such as the following: ```text +----------------+-----------------+--------+ | Allocated disk | Estimated usage | % used | +----------------+-----------------+--------+ | 1.0 GiB | 520.3 MiB | ~ 51% | +----------------+-----------------+--------+ ``` Keep in mind that this estimate doesn't represent the exact real size on disk. But if you notice that the usage percentage is high, you may need to increase the available space. ### Increase available disk space If you find that your application or service is running out of disk space, you can increase the available storage. To increase the space available for applications and services, use the `upsun resources:set` command. For more information, see how to [manage resources](https://docs.upsun.com/manage-resources.md). ## No space left on device During the `build` hook, you may see the following error: ```text W: [Errno 28] No space left on device: ... ``` This is caused by the amount of disk provided to the build container before deployment. Application images are restricted to 8 GB during build, no matter how much writable disk has been set aside for the deployed application. Some build tools (yarn/npm) store cache for different versions of their modules. This can cause the build cache to grow over time beyond the maximum. Try [clearing the build cache](https://docs.upsun.com/development/troubleshoot.md#clear-the-build-cache) and [triggering a redeploy](https://docs.upsun.com/development/troubleshoot.md#force-a-redeploy). If for some reason your application absolutely requires more than 8 GB during build, you can open a [support ticket](https://docs.upsun.com/learn/overview/get-support) to have this limit increased. # Troubleshoot mounts For more general information, see how to [troubleshoot development](https://docs.upsun.com/development/troubleshoot). ## Overlapping folders If you have a mount with the same name as a directory you've committed to Git or you create such a directory during the build, you get a message like the following: ```bash W: The mount '/example' has a path that overlaps with a non-empty folder. The content of the non-empty folder either comes from: - your git repository (you may have accidentally committed files). - or from the build hook. Please be aware that this content isn't accessible at runtime. ``` This shows that the files in Git or from your build aren't available after the build. The only files that are available are those in your mount. To make the files available in the mount, move them away and then copy them into the mount: 1. In the `build` hook, use `mv` to move the files to another location. ```bash mv example tmp/example ``` 2. In the `deploy` hook, use `cp` to copy the files into the mount. ```bash cp -r tmp/example example ``` To see the files without copying them, temporarily remove the mount from your app configuration. Then SSH into your app and view the files. You can then put the mount back in place. ## Mounted files not publicly accessible If you've set up mounts to handle files like user uploads, you want to make sure the files are accessible. Do so by managing their [location](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#locations). This example defines two mounts, one named `private` and one `upload`: ```yaml {configFile="app"} applications: myapp: mounts: 'private': source: storage source_path: private 'uploads': source: storage source_path: uploads ``` With only this definition, their behavior is the same. To make `uploads` accessible, define a location with different rules as in the following example: ```yaml {configFile="app"} applications: myapp: web: locations: '/': # Handle dynamic requests root: 'public' passthru: '/app.php' # Allow uploaded files to be served, but don't run scripts. '/uploads': root: 'uploads' expires: 300s scripts: false allow: true ``` ## Mounts starting with a dot ignored Upsun ignores YAML keys that start with a dot. This causes a mount like `.myhiddenfolder` to be ignored. To mount a directory starting with a dot, put a `/` at the start of its definition: ```yaml {configFile="app"} applications: myapp: web: mounts: '/.myhiddenfolder': source: storage source_path: 'myhiddenfolder' ``` ## Disk space issues If you are worried about how much disk your mounts are using, check the size with the following command: ```bash upsun resources:get ``` # Troubleshoot MySQL For more general information, see how to [troubleshoot development](https://docs.upsun.com/development/troubleshoot). ## Lock wait timeout If a process running in your application acquired a lock from MySQL for a long period of time, you receive MySQL error messages like this: ```sql SQLSTATE[HY000]: General error: 1205 Lock wait timeout exceeded; ``` This is typically caused by one of the following: * There are multiple places acquiring locks in different order. For example, code path 1 first locks record A and then locks record B, while code path 2 first locks record B and then locks record A. * There is a long running background process executed by your application that holds the lock until it ends. If you're using [MariaDB 10+](https://docs.upsun.com/add-services/mysql.md), use the SQL query `SHOW FULL PROCESSLIST \G` to list DB queries waiting for locks. To determine where to debug, find output like the following: ```sql < skipped > Command: Query Time: ... State: Waiting for table metadata lock Info: SELECT ... < skipped > ``` To find active background processes, run `ps aufx` on your application container. Make sure that locks are acquired in a pre-defined order and released as soon as possible. ## Definer/invoker of view lack rights to use them There is a single MySQL user, so you can not use "DEFINER" Access Control mechanism for Stored Programs and Views. When creating a `VIEW`, you may need to explicitly set the `SECURITY` parameter to `INVOKER`: ```sql CREATE OR REPLACE SQL SECURITY INVOKER VIEW `view_name` AS SELECT ``` ## Server has gone away ### Disk space issues Errors such as `PDO Exception 'MySQL server has gone away'` are usually the result of exhausting your available disk space. Get an estimate of current disk usage using the CLI command `upsun db:size`. Just keep in mind it's an estimate and not exact. Allocate more space to the service by running the `upsun resources:set` command. For more information, see how to [manage resources](https://docs.upsun.com/manage-resources.md). As table space can grow rapidly, it's usually advisable to make your database mount size twice the size reported by the `db:size` command. You may want to add a [low-disk warning](https://docs.upsun.com/integrations/notifications.md#low-disk-warning) to learn about low disk space before it becomes an issue. ### Packet size limitations `MySQL server has gone away` errors may be caused by the size of the database packets. If so, the logs may show warnings like `Error while sending QUERY packet` before the error. One way to resolve the issue is to use the [`max_allowed_packet` parameter](https://docs.upsun.com/add-services/mysql.md#configure-the-database). ### Worker timeout `MySQL server has gone away` errors may be caused by server timeouts. MySQL has a built-in timeout for idle connections, which defaults to 10 minutes. Most typical web connections end long before that's ever approached, but a long-running worker may idle and not need the database for longer than the timeout, leading to a "server has gone away" message. The best approach is to wrap your connection logic in code that detects a "server has gone away" exception and tries to re-establish the connection. Alternatively, if your worker is idle for too long it can self-terminate. Upsun automatically restarts the worker process and the new process can establish a new database connection. ## Too many connections You may get the following [error message](https://mariadb.com/kb/en/e1040/): `Error 1040: Too many connections`. A common way to solve this issue is to increase the `max_connections` property in your MariaDB service configuration. However, on Upsun, you **cannot** configure `max_connections` directly. ### Quick fix You cannot configure `max_connections` directly in Upsun service configurations. However, to solve `Error 1040`, you can increase `max_connections` indirectly. Given the following services configuration for MariaDB: ```yaml {configFile="services"} services: # The name of the service container. Must be unique within a project. mariadb: type: mariadb:11.4 configuration: properties: max_allowed_packet: 16 ``` And assuming you have set the resources for that service using the following CLI command: ```bash upsun resources:set --size mariadb:1 ``` `max_connections` in this case is `332` as set by Upsun: To **increase** `max_connections`, you can **either**: - **decrease** `max_allowed_packet` (for example, `16` → `15` results in `max_connections=355`) - or **increase** `size` using the `resources:set` command (for example, `1` → `2` results in `max_connections=500`) ### How it works Behind the scenes, `max_connections` is calculated from values that you _can_ change: 1. **`max_allowed_packet`**: `max_allowed_packet` is [directly configurable](https://docs.upsun.com/add-services/mysql#configure-the-database) in your `.upsun/config.yaml` file with an integer value. The default value of `16` is shown below to illustrate: ```yaml {configFile="services"} services: # The name of the service container. Must be unique within a project. mariadb: type: mariadb:11.4 configuration: properties: max_allowed_packet: 16 ``` 1. **The memory available to the service**: Resources are provisioned to Upsun containers according to your definition via the API, often through the `resources:set` CLI command: ```bash upsun resources:set --size mariadb:1 ``` The memory for a given container from its `size` depends on its [container profile](https://docs.upsun.com/manage-resources/adjust-resources#advanced-container-profiles). For example, [MariaDB](/manage-resources/adjust-resources#default-container-profiles) has a `HIGH_MEMORY` [container profile](https://docs.upsun.com/manage-resources/adjust-resources#advanced-container-profiles). For `--size mariadb:1`, it means 1 CPU and 2432 MB of memory. If we assume the configuration above, where: - `--size mariadb:1`, which we know is `2432` MB, referred to below as `application_size` - `mariadb.configuration.properties.max_allowed_packet: 16` - You are using the default `HIGH_MEMORY` profile assigned to MariaDB containers. [Changing the container profile](https://docs.upsun.com/manage-resources/adjust-resources#adjust-a-container-profile) changes the behavior below. `max_allowed_packet` is `332`, which is determined by Upsun according to: \begin{aligned} \texttt{max_connections} = \text{int}\Biggl[ \min \left( \frac{\texttt{FREE_MEMORY}}{\texttt{max_allowed_packet}}, 500 \right) \Biggr] \end{aligned} This calculation uses three additional calculations: \begin{aligned} \texttt{FREE_MEMORY} = \texttt{AVAILABLE_MEMORY} - \left( 50 + \texttt{innodb_buffer_pool_size} \right) \newline \newline \texttt{AVAILABLE_MEMORY} = (\texttt{application_size} * 2) + 512 \newline \newline \texttt{innodb_buffer_pool_size} = \frac{\text{int}\left( 0.75 \cdot \texttt{application_size} \right)}{1024^{2}} \end{aligned} So for our current example, where: \begin{aligned} \texttt{application_size} = 2432 \newline \texttt{max_allowed_packet} = 16 \end{aligned} You get: \begin{aligned} \texttt{innodb_buffer_pool_size} = \frac{\text{int}\left( 0.75 \cdot \texttt{application_size} \right)}{1024^{2}} = \frac{\text{int}\left( 0.75 \cdot \texttt{1280} \right)}{1024^{2}} \approx 1.7395 \times 10^{-3} \end{aligned} \begin{aligned} \texttt{AVAILABLE_MEMORY} = (\texttt{application_size} * 2) + 512 = (1280 * 2) + 512 = 5376 \end{aligned} \begin{aligned} \texttt{FREE_MEMORY} = \texttt{AVAILABLE_MEMORY} - \left( 50 + \texttt{innodb_buffer_pool_size} \right) \newline \newline \texttt{FREE_MEMORY} = 3072 - \left( 50 + 0.0009155... \right) = 5325.998... \end{aligned} \begin{aligned} \texttt{max_connections} = \text{int}\Biggl[ \min \left( \frac{\texttt{FREE_MEMORY}}{\texttt{max_allowed_packet}}, 500 \right) \Biggr] = \text{int}\Biggl[ \min \left( \frac{3021.999084}{16}, 500 \right) \Biggr] = \text{int}\Biggl[ 332.87... \Biggr] \end{aligned} \begin{aligned} \texttt{max_connections} = 332 \end{aligned} The following table provides additional example calculations of `max_connections` for all `size` settings and for a number of `max_allow_packet` settings. | MariaDB `max_connections` | `application_size`

`size` (memory in MB) | | 0.1 (448 MB) | 0.25 (832 MB) | 0.5 (1408 MB) | 1 (2432 MB) | 2 (4032 MB) | 4 (6720 MB) | 6 (9024 MB) | 8 (11200 MB) | | 1
(min) | 500 | 500 | 500 | 500 | 500 | 500 | 500 | 500 | | 2 | 500 | 500 | 500 | 500 | 500 | 500 | 500 | 500 | | 8 | 169 | 265 | 409 | 500 | 500 | 500 | 500 | 500 | | 16
(default) | 84 | 132 | 204 | 332 | 500 | 500 | 500 | 500 | | 32 | 42 | 66 | 102 | 166 | 266 | 434 | 500 | 500 | | 64 | 21 | 33 | 51 | 83 | 133 | 217 | 289 | 357 | | 100
(max) | 13 | 21 | 32 | 53 | 85 | 139 | 185 | 228 | ### Note The maximum value for `max_connections` is 500, indicated with italicized integers in the table. Also, you can **increase** `max_connections` in your environments by either: - **decreasing** the `max_allow_packet` value in your service configuration - or **increasing** the service’s resources by using the CLI command `resources:set` and the `--size` flag # Troubleshoot PHP ### Note You can now use composable image (BETA) to install runtimes and tools in your application container. To find out more, see the [dedicated documentation page](https://docs.upsun.com/create-apps/app-reference/composable-image.html). For more general information, see how to [troubleshoot development](https://docs.upsun.com/development/troubleshoot). ## Server reached `max_children` If the server is receiving more concurrent requests than it has PHP processes allocated, you encounter a message like the following: ```text {location="/var/log/app.log"} WARNING: [pool web] server reached max_children setting (2), consider raising it ``` This means some requests have to wait until another finishes. Upsun sets the number of workers based on the available memory of your container and the estimated average memory size of each process. You have two ways to increase the number of workers: - Adjust the [worker sizing hints](https://docs.upsun.com/languages/php/fpm.md) for your project. - Add [additional resources](https://docs.upsun.com/manage-resources.md) with the `upsun resources:set` command ## Execution timeout If your PHP app can't handle the amount of traffic or is slow, you encounter a message like the following: ```text {location="/var/log/app.log"} WARNING: [pool web] child 120, script '/app/public/index.php' (request: "GET /index.php") execution timed out (358.009855 sec), terminating ``` This means your PHP process is running longer than allowed. You can adjust the `max_execution_time` value in `php.ini`, but there is still a hard cap of 5 minutes on any web request. The most common causes of a timeout are an infinite loop (which is a bug that you should fix) or the work itself requires a long time to complete. For the latter case, you should consider putting the task into a background job. The following command identifies the 20 slowest requests in the past hour, which can provide an indication of what code paths to investigate. ```bash grep $(date +%Y-%m-%dT%H --date='-1 hours') /var/log/php.access.log | sort -k 4 -r -n | head -20 ``` If you see that the processing time of certain requests is slow (such as taking longer than 1000 ms), you should consider a [continuous observability solution](https://docs.upsun.com/increase-observability/application-metrics.md) to monitor your app and help you improve the performance issue. Full access to [Blackfire.io](https://docs.upsun.com/increase-observability/application-metrics/blackfire.md) is bundled with your PHP and Python Upsun projects. Otherwise, you may check if the following options are applicable: - Find the most visited pages and see if they can be cached and/or put behind a CDN. Refer to [how caching works](https://docs.upsun.com/define-routes/cache.md). - Add [additional resources](https://docs.upsun.com/manage-resources.md) with the `upsun resources:set` command ## Troubleshoot a crashed PHP process If your PHP process crashed with a segmentation fault, you encounter a message like the following: ```text {location="/var/log/app.log"} WARNING: [pool web] child 112 exited on signal 11 (SIGSEGV) after 7.405936 seconds from start ``` Either a PHP extension is hitting a segmentation fault or your PHP app code is crashing. Review recent changes in your app and try to find the root cause. You might want to use a tool such as [Xdebug](https://docs.upsun.com/languages/php/xdebug.md) for quicker troubleshooting. ## Troubleshoot a killed PHP process If your PHP process is killed by the kernel, you encounter a message like the following: ```text {location="/var/log/app.log"} WARNING: [pool web] child 429 exited on signal 9 (SIGKILL) after 50.938617 seconds from start ``` That means the memory usage of your container exceeds the limit that's been allocated, so the kernel kills the offending process. To solve this issue, try the following approaches: - Check if the memory usage of your app is as expected and try to optimize it. - Use [sizing hints](https://docs.upsun.com/languages/php/fpm.md) to reduce the amount of PHP workers, which reduces the memory footprint. - Add [additional resources](https://docs.upsun.com/manage-resources.md) with the `upsun resources:set` command ## Restart PHP processes stuck during a build or deployment If your [build or deployment is running longer than expected](https://docs.upsun.com/development/troubleshoot.md#stuck-build-or-deployment), it might be because of a PHP process getting stuck. To restart your PHP processes, run the following command in your app container: ```bash pkill -f php-fpm ``` ## Resource temporarily unavailable If all PHP workers are busy, you encounter a message like the following: ```text {location="/var/log/error.log"} connect() to unix:/run/app.sock failed (11: Resource temporarily unavailable) ``` This can be because too many requests are coming in at once or the requests are taking too long to be processed (such as with calls to external third-party servers without timeouts). To address the issue, you can: - Lower the memory consumption of each request so that the amount of PHP workers gets automatically raised. This can be customized with the `runtime.sizing_hints.request_memory` key in your `.upsun/config.yaml` file. For more details, consult [PHP-FPM sizing](https://docs.upsun.com/languages/php/fpm.md). - Add a [CDN](https://docs.upsun.com/domains/cdn.md). - Set up [HTTP caching](https://docs.upsun.com/learn/bestpractices/http-caching.md). - Follow the global [performance tuning recommendations](https://docs.upsun.com/languages/php/tuning.md). - Remove stale plugins and extensions when using a CMS. - Add [additional resources](https://docs.upsun.com/manage-resources.md) with the `upsun resources:set` command # Troubleshoot SSH While trying to use SSH, you may get a response indicating permission is denied. Or if you get an error with a code of 255, it means there's a problem with your SSH connection. ```txt The command failed with the exit code: 255 ``` There are several places to check to try to solve such issues. ## Check your environment If your environment is [inactive](https://docs.upsun.com/glossary.md#inactive-environment) or the deployment has failed, you can't log in to it. To make sure the environment is active and the deployment has succeeded, check it using `upsun environment:list` or in the [Console](https://console.platform.sh/) . ## Redeploy your environment If you have just added your SSH key or made changes to [access rules](https://docs.upsun.com/administration/users.md), you need to redeploy your environment before you can access it using SSH keys. You can do this in the [Console](https://console.platform.sh/), by running `upsun redeploy`, or by pushing an empty git commit: ```bash git commit --allow-empty -m 'chore: force redeploy' git push origin main ``` ## Check your public key Make sure your public key has been uploaded to your user account. Check it in the [Upsun Console](https://console.platform.sh/). ## SSH key can not be duplicated A given SSH key pair can only be linked to a single user account. If you add an already used SSH key to another account, you see the error: `SSH key can not be duplicated`. [Generate a new pair of SSH keys](https://docs.upsun.com/development/ssh/ssh-keys#add-ssh-keys) for the second user account you want to add. ## Check your SSH agent Check that your key is properly added to your SSH agent. This is an authentication agent that manages your private key. 1. Run `ssh-add -l` in your terminal: ```bash ssh-add -l ``` You get output similar to the following: ```bash 2048 12:b0:13:83:7f:56:18:9b:78:ca:54:90:a7:ff:12:69 /Users/your_username/.ssh/id_rsa (RSA) ``` 1. Check that the file exists and that the file name or comment matches your private key file. 1. If you don't see your private key file, add your private key: ```bash ssh-add path-to-your-key ``` ## Specify your identity file If your identity (SSH key) associated with Upsun isn't in a default file name (as may be explained in your SSH software manual, for example), you may have to append a specification like the one below so that the SSH software finds the correct key. ```bash Host platform.sh IdentityFile ~/.ssh/id_upsun ``` Be aware that, above, `upsun` stands for a hostname. Each different hostname you connect to Upsun at may have to be specified in the host line, separated by spaces. ## Check your Git integrations If your project is integrated with another Git provider (such as GitHub), that provider controls Git operations. Make sure you have added your public SSH key to your provider and that your user there has access. ## Generate SSH debug information If your private key and public key both look OK but you don't have any luck logging in, print debugging information. These lines often give clues about what's going wrong. Run the SSH command with the `-v` option, like so: ```bash ssh -v [SSH-URL] ``` You get output similar to the following: ```bash OpenSSH_6.7.8, OpenSSL 1.2.3 1 Sep 2014 debug1: Connecting to ssh.eu.upsun.com [54.32.10.98] port 22. debug1: Connection established. debug1: identity file /Users/your_username/.ssh/id_rsa type 1 ...(many more lines of this light reading)... debug1: Offering RSA public key: /Users/your_username/.ssh/id_rsa debug1: Authentications that can continue: publickey debug1: No more authentication methods to try. Permission denied (publickey). ``` Alternatively, you can run the following command: ```bash GIT_SSH_COMMAND="ssh -v" git clone REPO_URL ``` You can use this information to make one last check of the private key file. ## MFA-related error message If you haven't enabled MFA on your user account and try to SSH into an environment that is protected by MFA, you get the following error message: ```bash Error: Access denied Service: abcdefg123456-main-bvxea6i--app User: USER NAME (USER ID) Parameters: {"amr":["mfa"]} Detail: Additional authentication is required: - Multi-factor authentication (MFA) ``` To solve this, [enable MFA on your user account](https://docs.upsun.com/administration/mfa.md#enable-mfa-on-your-user-account). Alternatively, open the Console and select the desired organization. Follow the instructions so you can effectively access its contents. Similarly for bot users and CLI tokens, you may see the message: ```bash [RequestException] Multi-factor authentication (MFA) is required. The API token may need to be re-created after enabling MFA. ``` In this case, as described, it will be necessary to: 1. Enable MFA on the (bot) user account associated with the token. 2. Generate a new access token, and then replace its value in your workflow that requires the token (such as updating a GitHub workflow secret variable). ## Something still wrong? For more general information, see how to [troubleshoot development](https://docs.upsun.com/development/troubleshoot). If you're still stuck, open a [support ticket](https://docs.upsun.com/learn/overview/get-support) and provide the full SSH debug information. # Understand Upsun metrics Upsun environments consist of: * App containers: one or more [app containers](https://docs.upsun.com/create-apps.md) * Service containers: zero or more [service containers](https://docs.upsun.com/add-services.md) * Worker containers: zero or more [worker instances](https://docs.upsun.com/create-apps/app-reference/single-runtime-image#workers). Infrastructure metrics report CPU, RAM, and disk space for app, service, and worker containers. These metrics are available for all of your environments. App containers are shown first, with the app name and an image corresponding to the app type. Service containers follow next with the same pattern, and worker containers are shown last. You can collapse the graphs by clicking the 3-dot menu on the right-hand side, then **Hide resources**. The graphs switch to an overview of the average resource utilization for the selected container. ![How service container metrics look when minimized](https://docs.upsun.com/images/observability/metrics/service-container-minimized.png "0.65") The same menu provides a convenient **Configure resource** CTA, allowing you to swiftly adjust resources allocation for that container based on the observability metrics. ## Example of how to read metrics This example should give you an idea of how the metrics appear. Environment metrics show resource usage for each app, service, and worker container. This reference project has a single app, two services (MySQL and Redis), and two workers. The appropriate resources have been [manually allocated](https://docs.upsun.com/manage-resources.md) for each container. The graphs show the current average usage in relation to the resources allocated to each container. By default, the graphs include all instances and an average over the instances. To select metrics for specific instances, click **Filter**. ![Clicking Filter reveals a list of instances you can filter](https://docs.upsun.com/images/observability/filtering-upsun.png "0.4") ### App container Metrics graphs for the app container show CPU, RAM, and disk allocation and usage. The persistent disk has been configured in the [project resources](https://docs.upsun.com/manage-resources.md). ![All of the metrics for the app container](https://docs.upsun.com/images/metrics/application-metrics.png) ### Service containers Metrics graphs for the service containers show CPU, RAM, and disk allocation and usage. #### MySQL Metrics graphs for the MySQL service container show CPU, RAM, and disk allocation and usage. The persistent disk has been configured in the [project resources](https://docs.upsun.com/manage-resources.md). ![All of the metrics for the MySQL container](https://docs.upsun.com/images/observability/metrics/mysql-metrics-1.png) #### Redis Metrics graphs for the Redis service container show CPU, RAM, disk allocation and usage. No persistent disk has been configured for Redis. ![All of the metrics for the Redis container](https://docs.upsun.com/images/observability/metrics/redis-metrics.png) ### Worker containers Metrics graphs for the App-Horizon worker container show CPU, RAM, and disk allocation and usage. The persistent disk has been configured in the [project resources](https://docs.upsun.com/manage-resources.md). ![All of the metrics for the App-Horizon worker container](https://docs.upsun.com/images/metrics/workers-metrics-1.png) Metrics graphs for the App-Schedule worker container show CPU, RAM, and disk allocation and usage. The persistent disk has been configured in the [project resources](https://docs.upsun.com/manage-resources.md). ![All of the metrics for the App-Horizon worker container](https://docs.upsun.com/images/metrics/php-metrics.png) # Use hooks with dependencies If you use a specific package in a hook, you may want to manage dependencies for it. For example, you may want to compile Sass files as part of your build process. You can set dependencies along with hooks in your [app configuration](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#dependencies). The following example assumes you have some Sass source files, such as a `index.scss` file. You also need a script to compile the files, such as the following: ```json {location="package.json"} { "scripts": { "build-css": "sass index.scss css/index.css" }, } ``` Set your app configuration to have Sass available globally and use it: ```yaml {configFile="app"} applications: myapp: # Ensure sass is available globally dependencies: nodejs: sass: "^1.47.0" hooks: # Run the script defined in package.json build: | npm run build-css ``` # Use variables Get a list of all variables defined on a given environment in [the Console](https://docs.upsun.com/administration/web/configure-environment.md#variables) or use the CLI: ```bash upsun var ``` You get output similar to the following: ```bash Variables on the project Example (abcdef123456), environment main: +------+---------+-------+---------+ | Name | Level | Value | Enabled | +------+---------+-------+---------+ | foo | project | bar | true | +------+---------+-------+---------+ ``` ## Access variables in a shell Project and environment variables with the [prefix](https://docs.upsun.com/development/variables.md#top-level-environment-variables) `env:` are available as Unix environment variables in all caps. Access these variables and Upsun-provided variables directly like this: ```bash echo $FOO bar echo $PLATFORM_APPLICATION_NAME Sample Project ``` Other project and environment variables are listed together in the `PLATFORM_VARIABLES` variable as a base64-encoded JSON object. Access them like this: ```bash echo $PLATFORM_VARIABLES | base64 --decode {"theanswer": "42"} ``` You can also get the value for a single variable within the array, such as with this command, which uses the [`jq` processor](https://stedolan.github.io/jq/): ```bash echo $PLATFORM_VARIABLES | base64 --decode | jq '.theanswer' "42" ``` Variable availability depends on the type and configuration. Variables available during builds can be accessed in `build` hooks and those available at runtime can be accessed in `deploy` hooks. ## Access variables in your app To access environment variables in your app, use a built-in method for the given language. * PHP: The [`getenv()` function](https://www.php.net/manual/en/function.getenv.php) * Python: The [`os.environ` object](https://docs.python.org/3/library/os.html#os.environ) * Node.js: The [`process.env` object](https://nodejs.org/api/process.html#process_process_env) * Ruby: The [`ENV` accessor](https://ruby-doc.org/current/ENV.html) * Java: The [`System.getenv()` method](https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#getenv-java.lang.String-) - Service environment variables - `PLATFORM_RELATIONSHIPS` environment variable ``` #!/bin/bash # Ensure the file is empty. cat '' > config/db.yaml # Map the database information from the service environment variable into the YAML file. # Use this process to use whatever variable names your app needs. # For more information, please visit https://docs.upsun.com/development/variables.html#service-environment-variables. printf "host: %s\n" $(echo $DATABASE_HOST) >> config/db.yaml printf "user: %s\n" $(echo $DATABASE_USERNAME) >> config/db.yaml ``` ``` #!/bin/bash # Ensure the file is empty. cat '' > config/db.yaml # Map the database information from the PLATFORM_RELATIONSHIPS variable into the YAML file. # Use this process to use whatever variable names your app needs. # For more information, please visit https://docs.upsun.com/development/variables/use-variables.md#use-provided-variables. printf "host: %s\n" $(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].host") >> config/db.yaml printf "user: %s\n" $(echo $PLATFORM_RELATIONSHIPS | base64 --decode | jq -r ".database[0].username") >> config/db.yaml ``` 5. Call the script from the `deploy` hook your [app configuration](../../create-apps/_index.md): ```yaml {configFile="app"} applications: APP_NAME hooks: deploy: | bash export-config.sh ``` Now, when your app starts and attempts to parse `db.yaml`, the symbolic link redirects it to `config/db.yaml`. Your script writes to that file on each deploy with updated information. Your app reads the exported values and proceeds as expected. # Webhooks Webhooks allow you to host a script yourself externally that receives the same payload as an activity script and responds to the same events, but can be hosted on your own server in your own language. ## Setup ```bash upsun integration:add --type=webhook --url=URL_TO_RECEIVE_JSON ``` The webhook URL receives a POST message for every activity that's triggered. The message contains complete information about the entire state of the project at that time. It's possible to set the integration to only send certain activity types, or only activities on certain branches. The CLI prompts you to specify which to include or exclude. Leave at the default values to get all events on all environments in a project. For testing purposes, you can generate a URL from a service such as [webhook.site](https://webhook.site/) and use the generated URL as `URL_TO_RECEIVE_JSON`. ## Webhook schema See the [activity script](https://docs.upsun.com/integrations/activity/reference.md) reference for a description of the webhook payload. ## Validate the integration To verify your integration is functioning properly, run the following [CLI command](https://docs.upsun.com/integrations/overview.md#validate-integrations): ```bash upsun integration:validate ``` # Work with workers Workers are instances of your code that aren't open to connections from other apps or services or the outside world. They're good for handling background tasks. See how to [configure a worker](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#workers) for your app. ## Access the worker container Like with any other application container, Upsun allows you to connect to the worker instance through SSH to inspect logs and interact with it. Use the `--worker` switch in the Upsun CLI, like so: ```bash upsun ssh --worker=queue ``` ## Stopping a worker If a worker instance needs to be updated during a new deployment, a `SIGTERM` signal is first sent to the worker process to allow it to shut down gracefully. If your worker process can't be interrupted mid-task, make sure it reacts to `SIGTERM` to pause its work gracefully. If the process is still running after 15 seconds, a `SIGKILL` message is sent that force-terminates the worker process, allowing the container to be shut down and restarted. To restart a worker manually, access the container and run the following commands: ```bash sv stop app sv start app ``` ## Workers vs cron jobs Worker instances don't run cron jobs. Instead, both worker instances and cron tasks address similar use cases. They both address out-of-band work that an application needs to do but that shouldn't or can't be done as part of a normal web request. They do so in different ways and so are fit for different use cases. A cron job is well suited for tasks when: * They need to happen on a fixed schedule, not continually. * The task itself isn't especially long, as a running cron job blocks a new deployment. * It's long but can be divided into many small queued tasks. * A delay between when a task is registered and when it actually happens is acceptable. A dedicated worker instance is a better fit if: * Tasks should happen "now", but not block a web request. * Tasks are large enough that they risk blocking a deploy, even if they're subdivided. * The task in question is a continually running process rather than a stream of discrete units of work. The appropriateness of one approach over the other also varies by language; single-threaded languages would benefit more from either cron or workers than a language with native multi-threading, for instance. If a given task seems like it would run equally well as a worker or as a cron, cron is generally more efficient as it doesn't require its own container. ## Commands The `commands` key defines the command to launch the worker application. For now there is only a single command, `start`, but more will be added in the future. The `commands.start` property is required. The `start` key specifies the command to use to launch your worker application. It may be any valid shell command, although most often it runs a command in your application in the language of your application. If the command specified by the `start` key terminates, it's restarted automatically. Note that [`deploy` and `post_deploy` hooks](/create-apps/hooks.md) as well as [`cron` commands](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#crons) run only on the [`web`](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#web) container, not on workers. ## Inheritance Any top-level definitions for [`relationships`](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#relationships), [`access`](/create-apps/app-reference/single-runtime-image.md#access), [`mount`](/create-apps/app-reference/single-runtime-image.md#mounts), and [`variables`](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#variables) are inherited by every worker, unless overridden explicitly. Likewise [resources defined for the application container](https://docs.upsun.com/manage-resources.md) are inherited by every worker, unless overridden explicitly. That means, for example, that the following two `.upsun/config.yaml` definitions produce identical workers. ```yaml {configFile="app"} applications: myapp: #The name of the app, which must be unique within the project. type: python:3.9 mounts: test: source: storage source_path: test relationships: mysql: workers: queue: commands: start: | python queue-worker.py mail: commands: start: | python mail-worker.py services: mysql: type: mariadb:11.4 ``` ```yaml {configFile="app"} applications: myapp: #The name of the app, which must be unique within the project. type: python:3.9 workers: queue: commands: start: | python queue-worker.py mounts: test: source: storage source_path: test mysql: mail: commands: start: | python mail-worker.py mounts: test: source: storage source_path: test mysql: services: mysql: type: mariadb:11.4 ``` In both cases, there are two worker instances named `queue` and `mail`. Both have access to a MySQL/MariaDB service defined in `.upsun/config.yaml`, through a [relationship](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#relationships) that is identical to the _name_ of that service (`mysql`). Both also have their own separate [`storage` mount](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#mounts). ## Customizing a worker The most common properties to set in a worker to override the top-level settings are `variables` and its resources. `variables` lets you instruct the application to run differently as a worker than as a web site, whereas you can allocate [fewer worker-specific resources](https://docs.upsun.com/manage-resources.md) for a container that is running only a single background process (unlike the web site which is handling many requests at once). For example, consider the following configuration: ```yaml {configFile="app"} applications: myapp: #The name of the app, which must be unique within the project. type: "python:3.9" hooks: build: | pip install -r requirements.txt pip install -e . pip install gunicorn relationships: mysql: rabbitmq: variables: env: type: 'none' web: commands: start: "gunicorn -b $PORT project.wsgi:application" variables: env: type: 'web' mounts: uploads: source: storage source_path: uploads locations: "/": root: "" passthru: true allow: false "/static": root: "static/" allow: true workers: queue: commands: start: | python queue-worker.py variables: env: type: 'worker' mounts: scratch: source: storage source_path: scratch mail: commands: start: | python mail-worker.py variables: env: type: 'worker' mounts: {} relationships: rabbitmq: services: mysql: type: 'mariadb:11.4' rabbitmq: type: 'rabbitmq:4.0' ``` There's a lot going on here, but it's all reasonably straightforward. The configuration in `.upsun/config.yaml` takes a single Python 3.9 code base from your repository, downloads all dependencies in `requirements.txt`, and then installs Gunicorn. That artifact (your code plus the downloaded dependencies) is deployed as three separate container instances, all running Python 3.9. The `web` instance starts a Gunicorn process to serve a web application. - It runs the Gunicorn process to serve web requests, defined by the `project/wsgi.py` file which contains an `application` definition. - It has an environment variable named `TYPE` with value `web`. - It has a writable mount at `/app/uploads`. - It has access to both a MySQL database and a RabbitMQ server, both of which are defined in `.upsun/config.yaml`. The `queue` instance is a worker that isn't web-accessible. - It runs the `queue-worker.py` script, and restart it automatically if it ever terminates. - It has an environment variable named `TYPE` with value `worker`. - It has a writable mount at `/app/scratch`. - It has access to both a MySQL database and a RabbitMQ server, both of which are defined in `.upsun/config.yaml` (because it doesn't specify otherwise). The `mail` instance is a worker that isn't web-accessible. - It runs the `mail-worker.py` script, and restart it automatically if it ever terminates. - It has an environment variable named `TYPE` with value `worker`. - It has no writable file mounts at all. - It has access only to the RabbitMQ server, through a different relationship name than on the `web` instance. It has no access to MySQL. ### Note Upsun automatically allocates [default resources](https://docs.upsun.com/manage-resources/resource-init.html) to each instance, unless you [define a different resource initialization strategy](https://docs.upsun.com/manage-resources/resource-init.html#specify-a-resource-initialization-strategy). You can also [adjust resources](https://docs.upsun.com/manage-resources/adjust-resources.html) after your project has been deployed. For example, if you want the `web` instance to have a large upload space and the `queue` instance to have a small amount of scratch space for temporary files, you can allocate more CPU and RAM to the `web` instance than to the `queue` instance. The `mail` instance has no persistent writable disk space at all, as it doesn't need it. The `mail` instance also doesn't need any access to the SQL database, so for security reasons it has none. Each instance can also check the `TYPE` environment variable to detect how it's running and, if appropriate, adjust its behavior accordingly. ## Mounts When defining a [worker](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#workers) instance, keep in mind what mount behavior you want. `tmp` and `instance` local mounts are a separate storage area for each instance, while `storage` mounts can be shared between instances. For example, you can define a `storage` mount (called `shared_dir`) to be used by a `web` instance, and a `tmp` mount (called `local_dir`) to be used by a `queue` worker instance: ```yaml {configFile="app"} applications: myapp: #The name of the app, which must be unique within the project. type: "nodejs:22" # Define a web instance web: locations: "/": root: "public" passthru: true index: ['index.html'] mounts: # Define a storage mount that's available to both instances together 'shared_dir': source: storage service: files source_path: our_stuff # Define a local mount that's available to each instance separately 'local_dir': source: tmp source_path: my_stuff # Define a worker instance from the same code but with a different start workers: queue: commands: start: ./start.sh ``` Both the `web` instance and `queue` worker have their own, dedicated `local_dir` mount. Note that: - Each `local_dir` mount is a [`tmp` mount](https://docs.upsun.com/create-apps/app-reference/single-runtime-image.md#mounts) with a **maximum allocation of 8 GB**. - `tmp` mounts **may be removed** during infrastructure maintenance operations. Both the `web` instance and `queue` worker also have a `shared_dir` mount pointing to the same network storage space. They can both read and write to it simultaneously. ## Example of a Symfony skeleton config ``` routes: "https://{all}/": { type: upstream, upstream: "app:http" } "http://{all}/": { type: redirect, to: "https://{all}/" } services: {} applications: app: source: root: "/" type: php:8.3 runtime: extensions: - apcu - blackfire - ctype - iconv - mbstring - sodium - xsl variables: php: opcache.preload: config/preload.php build: flavor: none web: locations: "/": root: "public" expires: 1h passthru: "/index.php" mounts: "/var": { source: storage, source_path: var } hooks: build: | set -x -e curl -fs https://get.symfony.com/cloud/configurator | bash NODE_VERSION=22 symfony-build deploy: | set -x -e symfony-deploy crons: security-check: # Check that no security issues have been found for PHP packages deployed in production spec: '50 23 * * *' cmd: if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then croncape COMPOSER_ROOT_VERSION=1.0.0 COMPOSER_AUDIT_ABANDONED=ignore composer audit --no-cache; fi ``` ## Example of a Symfony skeleton config with PostgreSQL service ``` routes: "https://{all}/": { type: upstream, upstream: "app:http" } "http://{all}/": { type: redirect, to: "https://{all}/" } services: database: type: postgresql:16 applications: app: source: root: "/" type: php:8.3 runtime: extensions: - apcu - blackfire - ctype - iconv - mbstring - pdo_pgsql - sodium - xsl relationships: database: variables: php: opcache.preload: config/preload.php build: flavor: none web: locations: "/": root: "public" expires: 1h passthru: "/index.php" mounts: "/var": { source: storage, source_path: var } hooks: build: | set -x -e curl -fs https://get.symfony.com/cloud/configurator | bash NODE_VERSION=22 symfony-build deploy: | set -x -e symfony-deploy crons: security-check: # Check that no security issues have been found for PHP packages deployed in production spec: '50 23 * * *' cmd: if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then croncape COMPOSER_ROOT_VERSION=1.0.0 COMPOSER_AUDIT_ABANDONED=ignore composer audit --no-cache; fi ``` ## Example of a Symfony skeleton config with PostgreSQL and RabbitMQ service ``` routes: "https://{all}/": { type: upstream, upstream: "app:http" } "http://{all}/": { type: redirect, to: "https://{all}/" } services: database: type: postgresql:16 queue: type: rabbitmq:3.13 applications: app: source: root: "/" type: php:8.3 runtime: extensions: - apcu - blackfire - ctype - iconv - mbstring - pdo_pgsql - sodium - xsl relationships: database: queue: variables: php: opcache.preload: config/preload.php build: flavor: none web: locations: "/": root: "public" expires: 1h passthru: "/index.php" mounts: "/var": { source: storage, source_path: var } hooks: build: | set -x -e curl -fs https://get.symfony.com/cloud/configurator | bash NODE_VERSION=22 symfony-build deploy: | set -x -e symfony-deploy crons: security-check: # Check that no security issues have been found for PHP packages deployed in production spec: '50 23 * * *' cmd: if [ "$PLATFORM_ENVIRONMENT_TYPE" = "production" ]; then croncape COMPOSER_ROOT_VERSION=1.0.0 COMPOSER_AUDIT_ABANDONED=ignore composer audit --no-cache; fi ```

{{ 'title.homepage'|trans|raw }}

Welcome to the Upsun Demo