> ## Documentation Index > Fetch the complete documentation index at: https://developer.upsun.com/llms.txt > Use this file to discover all available pages before exploring further. # Configure apps > Control your apps and how they're built and deployed on Upsun Cloud with YAML configuration. Within a single project, you can have one or more apps and each app can have multiple instances. Instances are where the same code can be run with different configurations, such as one for external communication and one for background processes. Apps and instances use similar properties, with minor differences depending on the image type that you choose: * [Single-runtime image](https://developer.upsun.com/docs/configure-apps/app-reference/single-runtime-image.md) * [Composable image](https://developer.upsun.com/docs/configure-apps/app-reference/composable-image.md) Not sure which image type to use? See [choosing an image type](https://developer.upsun.com/docs/configure-apps/app-reference). ## A minimal application To create a very basic app (for this example, using a single-runtime image), you need a few things: * A unique name not shared by any other app in the project. * The runtime `type` defining what language it uses. * A definition of how to handle requests from the outside `web`. The following example shows such a basic setup for Node.js: \# Top-level key, which contains configurations for all app containers. applications: \# The app's name, which must be unique within the project. myapp: \# The language and version for your app. type: 'nodejs:\{\{version:nodejs:latest}}' \# The app's configuration when it's exposed to the web. web: commands: start: npm start locations: '/': \# The public directory relative to the app root. root: 'public' \# Forward resources to the app. passthru: true \# What files to use when serving a directory. index: \["index.html"] \# Allow files even without specified rules. allow: true ## Use multiple apps You might have multiple apps you want to run from a single Git repository, such as a RESTful web service and a front-end or a main website and a blog. In such cases, you configure each app separately and define the relationships among them. See the various ways to set up a [multi-app project](https://developer.upsun.com/docs/configure-apps/multi-app). ## Connect to services If you want to use one of the [databases or other services Upsun Cloud provides](https://developer.upsun.com/docs/add-services), set it up by following these steps: 1. Configure the service based on the documentation for that service. 2. Use the information from that service inside your app's [`relationships` definition](https://developer.upsun.com/docs/configure-apps/image-properties/relationships) to configure how your app communicates with the service. ## Control the build and deploy process Your app generally needs to undergo some steps to be turned from the code in your Git repository into a running app. If you're running a PHP or Node.js app, this starts with the [build flavor](https://developer.upsun.com/docs/configure-apps/app-reference/single-runtime-image.md#build), which runs a default set of tasks. Then any [global dependencies](https://developer.upsun.com/docs/configure-apps/app-reference/single-runtime-image.md#dependencies) can be installed. Once these optional tasks are done, you can run [hooks](https://developer.upsun.com/docs/configure-apps/hooks) at various points in the process. Hooks are places for your custom scripts to control how your app is built and deployed. ## Configure what's served Once your app is built, it needs a defined way to communicate with the outside world. Define its behavior with a [`web` instance](https://developer.upsun.com/docs/configure-apps/image-properties/web). There you can set what command runs every time your app is restarted, how dynamic requests are handled, and how to respond with static files. ## Response compression Response compression reduces payload sizes and generally increases your app's response times. Requests for static files that are served directly by Upsun Cloud are compressed automatically using either gzip or Brotli compression if: * The request headers for the file support gzip or Brotli compression. * The file is served directly from disk by Upsun Cloud and not passed through your application. * The file would be served with a cache expiration time in the future. * The file type is one of: HTML, JavaScript, JSON, PDF, PostScript, SVG, CSS, CSV, plain text, or XML. Also, if there is a request for a file and another file exists with the same name plus a `.gz` or `.br` extension, the compressed file is served regardless of the original file type. So a request for `styles.css` that accepts a gzipped file (according to the request headers) automatically returns a `styles.css.gz` file if it exists. This approach supports any file type and offers some CPU optimization, especially if the cache lifetime is short. Dynamic responses generated by your app aren't compressed by default, because compressing them reintroduces the theoretical [BREACH](https://en.wikipedia.org/wiki/BREACH) attack surface. If your framework mitigates BREACH, which most do by default, you can opt in per location with the [`dynamic_compression` setting](https://developer.upsun.com/docs/configure-apps/image-properties/web#dynamic-response-compression). ## Comprehensive example > [!NOTE] > > PHP specifics > Unlike other runtimes, most PHP applications do not have a start command. There is a daemon running configured to work automatically with the web server. More often than not there will be a single entry-point a "front-controller". In the case of PHP the `passthru` property is a string with the location of the front-controller rather than a boolean. The following example shows a setup for a PHP app with comments to explain the settings. > [tab] Single-runtime image > > applications: > \# The app's name, which must be unique within the project. > \: > \# The language and version for your app. > type: 'php:\{\{version:php:latest}}' > > \# Relationships enable an app container's access to a service or another app. > \# The example below shows simplified configuration leveraging a default service > \# (identified from the relationship name) and a default endpoint. > \# See the Application reference for all options for defining relationships and endpoints. > relationships: > mysql: > > \# Scripts that are run as part of the build and deploy process. > hooks: > \# Build hooks can modify app files on disk but not access any services like databases. > build: ./build.sh > \# Deploy hooks can access services but the file system is now read-only. > deploy: ./deploy.sh > \# Post deploy hooks run when the app is accepting outside requests. > post\_deploy: ./post\_deploy.sh > > \# Define writable, persistent filesystem mounts. > \# The key is the directory path relative to the application root. > \# In this case, \`web-files\` is just a unique name for the mount. > mounts: > 'web/files': > source: storage > source\_path: 'web-files' > > \# The app's configuration when it's exposed to the web. > web: > locations: > '/': > \# The app's public directory relative to its root. > root: 'public' > \# A front controller to determine how to handle requests. > passthru: '/app.php' > \# Allow uploaded files to be served, but don't run scripts. > \# Missing files get sent to the front controller. > '/files': > root: 'web/files' > scripts: false > allow: true > passthru: '/app.php' > > services: > mysql: > type: mariadb:\{\{version:mariadb:latest}} > [tab] Composable image > > applications: > \# The app's name, which must be unique within the project. > \: > \# The list of packages you want installed (from the Upsun Cloud collection > \# of supported runtimes and/or from Nixpkgs). > \# For more information, see the Composable image page in the App reference section. > type: "composable:\{\{version:composable:latest}}" > stack: > runtimes: > \- "php\@8.4": > \# The list of PHP extensions you want installed. > extensions: > \- apcu > \- ctype > \- iconv > \- mbstring > \- pdo\_pgsql > \- sodium > \- xsl > disabled\_extensions: > \- gd > \- "nodejs@\{\{version:nodejs:latest}}" > packages: > \- yarn > \- imagemagick > \- package: wkhtmltopdf > channel: unstable > \# Relationships enable an app container's access to a service or another app. > \# The example below shows simplified configuration leveraging a default service > \# (identified from the relationship name) and a default endpoint. > \# See the Application reference for all options for defining relationships and endpoints. > relationships: > mysql: > > \# Scripts that are run as part of the build and deploy process. > hooks: > \# Build hooks can modify app files on disk but not access any services like databases. > build: ./build.sh > \# Deploy hooks can access services but the file system is now read-only. > deploy: ./deploy.sh > \# Post deploy hooks run when the app is accepting outside requests. > post\_deploy: ./post\_deploy.sh > > \# Define writable, persistent filesystem mounts. > \# The key is the directory path relative to the application root. > \# In this case, \`web-files\` is just a unique name for the mount. > mounts: > 'web/files': > source: storage > source\_path: 'web-files' > > \# The app's configuration when it's exposed to the web. > web: > locations: > '/': > \# The app's public directory relative to its root. > root: 'public' > \# A front controller to determine how to handle requests. > passthru: '/app.php' > \# Allow uploaded files to be served, but don't run scripts. > \# Missing files get sent to the front controller. > '/files': > root: 'web/files' > scripts: false > allow: true > passthru: '/app.php' > > services: > mysql: > type: mariadb:\{\{version:mariadb:latest}} This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.