An Introduction to App Platform

App Platform is a Platform-as-a-Service (PaaS) offering that allows developers to publish code directly to DigitalOcean servers without worrying about the underlying infrastructure.

What is App Platform?

App Platform is a Platform-as-a-Service (PaaS) offering that allows developers to continually publish web applications and static sites directly to DigitalOcean’s hosting servers without needing to set up any of the usual underlying infrastructure, such as servers and runtime environments.

You can connect App Platform directly to your application’s code repository and configure it to monitor your repo for changes, which it immediately deploys. App Platform then hosts the application at a public URL.

How does App Platform work?

App Platform can deploy your Dockerfiles or build image containers for your applications and deploy them.

If your app doesn’t use a Dockerfile, App Platform deploys your app by running the following steps:

1. Reads the code in your app’s repository.
2. Assesses the app’s language and dependencies (using CNCF buildpacks).
3. Builds a container image for the app based on that assessment.
4. Runs the container image with your app inside of it.
5. Hosts the application or site at a public URL provided by DigitalOcean or a domain that you provide.

For example, if you have a NodeJS application that use the Axios and Mocha packages, App Platform automatically sets up NodeJS and installs those packages in a container image along with your app. App Platform then runs the container on a shared DigitalOcean Kubernetes cluster and makes it publicly accessible.

Additionally, if your application or site requires other elements like databases, worker services, or serverless functions, you can add those components as needed to the app at any time.

The infrastructure of an app deployed to App Platform looks like this:

The infrastructure of a static site deployed to App Platform looks like this:

What are the use cases for App Platform?

App Platform is ideal for developers who don’t want to manage and maintain their own servers when hosting a web app. You can deploy a broad variety of different web applications to App Platform, including NodeJS, Python, Go, and Ruby apps. You can also deploy static websites such as Jamstack-style sites, plain HTML websites, and websites that use frameworks like Hugo or Jekyll.

Some common use cases include:

• Ruby on Rails apps that use:

  • Web services to run a dynamic website or API.
  • Workers to process delayed tasks (using sidekiq).
  • MySQL/PostgreSQL as relational databases to power an app or API.
  • Redis for queueing delayed tasks with sidekiq.
  • Job (pre-deploy) to run migrations.

• Django apps that use:

  • Web services to run the main part of a website or app.
  • Workers to process delayed tasks (with Celery).
  • MySQL/PostgreSQL as a relational databases to power a website or API.
  • Redis for queuing using Celery.
  • Job (pre-deploy) to run migrations.

• Static sites with dynamic behavior that use:

  • Static site frameworks (NextJS, React, Hugo).
  • Jamstack-style architecture.
  • Serverless functions.

What are components in App Platform?

Components are additional pieces of functionality hosted by DigitalOcean that you can configure and add to your app at anytime. Components include:

• Services - Apps are services by default, but you can add additional services to support your web app, such as a second API. Services have internet-accessible endpoints. If you only need your app to access the service, you can create an internal service.
• Workers - While services are publicly accessible from the internet, background workers are not. They can contain any application code you like, but cannot be accessed from the internet. Some examples of background workers include applications that delete old logs, resize images in a Space, or periodically write entries into a database.
• Databases - Repositories for your data. You can connect any DigitalOcean hosted database to your app, including MySQL, PostgreSQL, and MongoDB databases. We also offer a number of bindable environment variables that automatically contain sensitive information about your database. You can use these variables anywhere in your application’s code.
• Jobs - Any code that you would like to run at specific times. Currently, you can only schedule jobs to run pre- or post-deployment, not during deployment. You can also configure jobs to only run if a deployment fails or not.
• Serverless Functions - Blocks of code you can run without any self-managed infrastructure. Any serverless functions you build and deploy can be accessed from the web, and you are only billed for the time that the function is running. Functions can contain any functional piece of code and be used for such things as APIs for Jamstack style websites, basic web services that process images and upload them storage services, or handlers that process web form data.

What is the difference between using buildpacks and Dockerfiles to deploy an application?

When you deploy your application to App Platform, you can deploy your app using either Cloud Native Buildpacks or Dockerfiles:

• Dockerfiles - Custom container images that you provide and contain all of the utilities, system libraries, and configurations your application needs to run. Dockerfile images are immutable, meaning your application can only be updated by deploying a new version of the container image.  If you want to use Dockerfiles to deploy your app to App Platform, you can store the image file in the root of your code repository or in a DigitalOcean’s Container Registry. Dockerfiles allow you to deploy whatever application you want onto App Platform as long as the container is OCI-compliant (Open Container Initiative).

• Cloud Native Buildpacks - Container images built from predefined build packs that contain a popular system libraries and tools specific to your app’s programming language. If you do not provide a container image for your app, App Platform assesses your application’s language and dependencies and builds an OCI-compliant container image from a Cloud Native Buildpack to deploy your application into. Buildpacks are not customizable but contain most common dependencies for modern applications. Deploying your app using buildpacks is fine for most use cases and relieves you from needing to build and manage a container file for your application. See our reference documentation to see which buildpacks we currently support.

How do deployments work?

When you redeploy an app with its latest changes, App Platform keeps the previous instance of the app running until the new instance is considered healthy and ready to serve traffic.

The deployment flow is as follows:

1. App Platform builds a new container for the app with the latest changes.
2. Once App Platform determines that the new instance is healthy, it adds the instance to the load balancer to start receiving traffic.
3. App Platform then marks the old instance for termination and removes it from the load balancer. Once removed from the load balancer, the old instance no longer receives traffic.
4. The old instance then receives the SIGTERM signal to shut down and the app can perform any cleanup operations before terminating. The default termination grace period is 30 seconds, but you can change this value in your app’s spec.
5. This process repeats until all instances have been replaced.