Tutorial: Deploy a Quarkus web app to Azure App Service and PostgreSQL

In this tutorial, you deploy a Java 25 data-driven Quarkus 3.38.1 web application to Azure App Service with Azure Database for PostgreSQL flexible server 16. The AZD workflow also provisions Azure Managed Redis. Azure App Service supports Java Standard Edition (Java SE) in a Windows or Linux server environment.

In this tutorial, you learn how to:

• Create a secure-by-default architecture for Azure App Service and Azure Database for PostgreSQL flexible server.
• Secure connection secrets using a managed identity and Key Vault reference.
• Deploy a sample Quarkus app to App Service from a GitHub repository.
• Access App Service app settings in the application code.
• Make updates and redeploy the application code.
• Generate database schema by running database migrations.
• Stream diagnostic logs from Azure.
• Manage the app in the Azure portal.
• Provision an expanded architecture with Azure Managed Redis and deploy it by using Azure Developer CLI.
• Optimize your development workflow with GitHub Codespaces and GitHub Copilot.

Prerequisites

• An Azure account with an active subscription. If you don't have an Azure account, you can create one for free.
• A GitHub account. You can also get one for free.
• Knowledge of Java with Quarkus development.
• (Optional) To try GitHub Copilot, a GitHub Copilot account. A 30-day free trial is available.

• An Azure account with an active subscription. If you don't have an Azure account, you can create one for free.
• A GitHub account. You can also get one for free.
• Azure Developer CLI installed. You can follow the steps with the Azure Cloud Shell because it already has Azure Developer CLI installed.
• Knowledge of Java with Quarkus development.
• (Optional) To try GitHub Copilot, a GitHub Copilot account. A 30-day free trial is available.

Skip to the end

If you just want to see the sample app in this tutorial running in Azure, run the following commands in Azure Cloud Shell and follow the prompts. The environment name must be no more than 25 characters so that generated Azure Managed Redis names satisfy cross-region naming limits.

git clone https://github.com/Azure-Samples/msdocs-quarkus-postgresql-sample-app
cd msdocs-quarkus-postgresql-sample-app
azd auth login
azd env new <environment-name>
azd provision --preview
azd up

1. Run the sample

First, set up a sample data-driven app as a starting point. For your convenience, the sample repository, Hibernate ORM with Panache and RESTEasy, includes a dev container configuration. The dev container provides Java 25, the development tools, PostgreSQL 16, and the environment variables needed to run the sample locally. It doesn't provide a local Redis service. The dev container can run in a GitHub codespace, which means you can run the sample on any computer with a web browser.

Step 1: In a new browser window:

1. Sign in to your GitHub account.
2. Navigate to https://github.com/Azure-Samples/msdocs-quarkus-postgresql-sample-app/fork.
3. Unselect Copy the main branch only. You want all the branches.
4. Select Create fork.

Step 2: In the GitHub fork:

1. Select main > starter-no-infra for the starter branch. This branch contains just the sample project and no Azure-related files or configuration.
2. Select Code > Create codespace on starter-no-infra. The codespace takes a few minutes to set up.

Step 2: In the GitHub fork, leave main selected and select Code > Create codespace on main. This branch contains the sample application and its AZD configuration. The codespace takes a few minutes to set up.

Step 3: In the codespace terminal:

1. Run mvn quarkus:dev.
2. Ignore the notification Your application running on port 5005 is available.
3. When you see the notification Your application running on port 8080 is available., select Open in Browser. You should see the sample application in a new browser tab. To stop the Quarkus development server, type Ctrl+C. The first startup on Java 25 can take a few minutes while Maven downloads dependencies and Quarkus initializes.

For more information on how the Quarkus sample application is created, see Quarkus documentation Simplified Hibernate ORM with Panache and Configure data sources in Quarkus.

Tip

You can ask GitHub Copilot about this repository. For example:

• @workspace What does this project do?
• @workspace What does the .devcontainer folder do?

Having issues? Check the Troubleshooting section.

2. Create App Service and PostgreSQL

In this step, you create the Azure resources for the portal workflow. The completed app uses Java 25, Quarkus 3.38.1, and Azure Database for PostgreSQL flexible server 16. For the creation process, specify:

• The Name for the web app. It's used as part of the DNS name for your app in the form of https://<app-name>-<hash>.<region>.azurewebsites.net.
• The Region to run the app physically in the world. It's also used as part of the DNS name for your app.
• The Runtime stack for the app. It's where you select the version of Java to use for your app.
• The Hosting plan for the app. It's the pricing tier that includes the set of features and scaling capacity for your app.
• The Resource Group for the app. A resource group lets you group (in a logical container) all the Azure resources needed for the application.

Sign in to the Azure portal and follow these steps to create your Azure App Service resources.

Step 1: In the Azure portal:

1. In the top search bar, type app service.
2. Select the item labeled App Service under the Services heading.
3. Select Create > Web App. You can also navigate to the creation wizard directly.

Step 2: Configure the new app Fill out the form as follows.

1. Name: msdocs-quarkus-postgres. A resource group named msdocs-quarkus-postgres_group is generated for you.
2. Runtime stack: Java 25.
3. Java web server stack: Java SE (Embedded Web Server).
4. Operating system: Linux.
5. Region: Any Azure region near you.
6. Linux Plan: Create new and use the name msdocs-quarkus-postgres.
7. Pricing plan: Basic B1. When you're ready, you can scale up to a different pricing tier.

Step 3: Add database

1. Select the Database tab.
2. Select Create a Database.
3. In Engine, select PostgreSQL - Flexible Server. The server name and database name are set by default to appropriate values.
4. In PostgreSQL version, select or verify 16.

Step 4: Configure GitHub deployment

1. Select the Deployment tab.
2. Select Continuous deployment.
3. If this is your first time configuring GitHub deployment in App Service, select Authorize and authenticate with your GitHub account.
4. In Organization, select your GitHub alias.
5. In Repository, select msdocs-quarkus-postgresql-sample-app.
6. In Branch, select starter-no-infra.
7. Select Review + create.
8. After validation completes, select Create. By default, the create wizard creates a user-assigned identity for the workflow to authenticate using Microsoft Entra (OIDC authentication). For alternative authentication options, see Deploy to App Service using GitHub Actions.

Step 5: The deployment takes a few minutes to complete. When the deployment finishes, select the Go to resource button. You're taken directly to the App Service app. The wizard creates the following resources:

• Resource group: The container for all the created resources.
• App Service plan: Defines the compute resources for App Service. A Linux plan in the Basic tier is created.
• App Service: Represents your Java 25 app and runs in the App Service plan.
• Virtual network: Integrated with the App Service app and isolates back-end network traffic.
• Azure Database for PostgreSQL flexible server 16: Accessible only from within the virtual network. The wizard creates a database and a user for you on the server.
• Private DNS zone: Enables DNS resolution of the PostgreSQL server in the virtual network.

3. Secure connection secrets

The creation wizard generated the connectivity variables for you already as app settings. However, the security best practice is to keep secrets out of App Service completely. You'll move your secrets to a key vault and change your app setting to Key Vault references with the help of Service Connectors.

Step 1: Retrieve the existing connection string

1. In the left menu of the App Service page, select Settings > Environment variables.
2. Select Connection strings.
3. Select AZURE_POSTGRESQL_CONNECTIONSTRING.
4. In Add/Edit application setting, in the Value field, find the User Id= and Password= parts at the end of the string.
5. Copy the username and password strings after User Id= and Password= for use later. This app setting lets you connect to the Postgres database secured behind a private endpoint. However, the secret is saved directly in the App Service app, which isn't the best. You'll change this.

Step 2: Create a subnet for securing Key Vault The virtual network already has two subnets, but one is delegated to App Service and the other is delegated to Azure Database for PostgreSQL. Create another subnet for secure access to Key Vault with a private endpoint.

1. In the left menu of the App Service page, select the Overview tab.
2. Select the resource group of the app.
3. Select the virtual network in the resource group.
4. In the left menu of the virtual network, select Settings > Subnets.
5. Select + Subnet.
6. In Name, type subnet-keyvault. Accept the defaults.
7. Select Add.

Step 3: Create a key vault for secure management of secrets

1. In the top search bar, type "key vault", then select Marketplace > Key Vault.
2. In Resource Group, select msdocs-quarkus-postgres_group.
3. In Key vault name, type a name that consists of only letters and numbers.
4. In Region, set it to the same location as the resource group.

Step 4: Secure the key vault with a Private Endpoint

1. Select the Networking tab.
2. Unselect Enable public access.
3. Select Create a private endpoint.
4. In Resource Group, select msdocs-quarkus-postgres_group.
5. In the dialog, in Location, select the same location as your App Service app.
6. In Name, type msdocs-quarkus-postgresVaultEndpoint.
7. In Virtual network, select vnet-xxxxxxx.
8. In Subnet, subnet-keyvault.
9. Select OK.
10. Select Review + create, then select Create. Wait for the key vault deployment to finish. You should see "Your deployment is complete."

Step 5: Create a PostgreSQL connector

1. In the top search bar, type msdocs-quarkus-postgres, then select the App Service resource called msdocs-quarkus-postgres.
2. In the App Service page, in the left menu, select Settings > Service Connector > Create.
3. In Service type, select DB for PostgreSQL flexible server.
4. In PostgreSQL flexible server, msdocs-quarkus-postgres-server should be selected already.
5. In PostgreSQL database, select msdocs-quarkus-postgres-database.
6. In Client type, select Java.

Step 6: Save PostgreSQL secrets in key vault

1. Select the Authentication tab.
2. Select Connection string.
3. In Username and Password, paste the password you copied earlier.
4. Select Store Secret in Key Vault.
5. Under Key Vault Connection, select Create new. A Create connection dialog is opened on top of the edit dialog.

Step 7: Establish the Key Vault connection

1. In the Create connection dialog for the Key Vault connection, in Key Vault, select the key vault you created earlier.
2. In Client type, select Java for consistency. Your application code doesn't actually use the key vault directly.
3. Select Review + Create.
4. When validation completes, select Create.

Step 8: Finalize the PostgreSQL connector settings

1. You're back in the edit dialog for the PostgreSQL connector. In the Authentication tab, wait for the key vault connector to be created. When it's finished, the Key Vault Connection dropdown automatically selects it.
2. Select Review + Create.
3. When validation completes, select Create. Wait until the Creation succeeded notification appears.

Step 9: Verify the Key Vault integration

1. From the left menu, select Settings > Environment variables again.
2. Next to AZURE_POSTGRESQL_CONNECTIONSTRING, select Show value. The value should be @Microsoft.KeyVault(...), which means that it's a key vault reference because the secret is now managed in the key vault.

Step 10: Delete the original database credentials from App Service

1. Select the Connection strings tab.
2. To the right of AZURE_POSTGRESQL_CONNECTIONSTRING, select Delete. Remember that the create wizard created this connection string for you at the beginning.

To summarize, the process for securing your connection secrets involved:

• Retrieving the connection secrets from the App Service app's environment variables.
• Creating a key vault with a private endpoint.
• Creating a Key Vault connection with the system-assigned managed identity.
• Creating a PostgreSQL Service Connector that stores connection secrets in the key vault.
• Deleting the old PostgreSQL connection string from the App Service app.

Having issues? Check the Troubleshooting section.

4. Deploy sample code

In the create wizard, you already configured continuous deployment from your sample GitHub repository using GitHub Actions. It's just one of many ways to deploy to App Service, but also a great way to have continuous integration in your deployment process. By default, every git push to your GitHub repository kicks off the build and deploy action.

Note the following:

• Quarkus listens to port 8080 by default. In production, it needs to be configured to listen to the port specified by the PORT environment variable in App Service.
• Your deployed Java package must be an Uber-Jar.
• For simplicity of the tutorial, you'll disable tests during the deployment process. The GitHub Actions runners don't have access to the PostgreSQL database in Azure, so any integration tests that require database access will fail, such as is the case with the Quarkus sample application.
• The first Java 25 startup can take a few minutes. App Service continues sending warmup requests while Quarkus initializes.

Step 1: Back in the GitHub codespace of your sample fork, run git pull origin starter-no-infra. This pulls the newly committed GitHub workflow file into your codespace.

Step 2: Configure Java 25 startup

1. In the App Service page, select Settings > Environment variables.
2. On the App settings tab, select Add.
3. For Name, enter JAVA_OPTS.
4. For Value, enter the following value on one line:

--add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED

5. Select Apply, and then select Confirm.

The application on Java 25 requires these module-opening options.

Step 3: Configure Quarkus for App Service

1. Open src/main/resources/application.properties in the codespace.
2. Ensure that schema management uses the current quarkus.hibernate-orm.schema-management.strategy property name. For example, the development configuration can use quarkus.hibernate-orm.schema-management.strategy=drop-and-create.
3. Add or update the production properties so that they match the following example:

%prod.quarkus.datasource.jdbc.url=${AZURE_POSTGRESQL_CONNECTIONSTRING}
quarkus.package.jar.type=uber-jar
%prod.quarkus.http.port=${PORT}

The PostgreSQL connection string is supplied by Service Connector through AZURE_POSTGRESQL_CONNECTIONSTRING.

Step 4: Configure the GitHub Actions build

1. Open .github/workflows/starter-no-infra_msdocs-quarkus-postgres.yml. This file is the GitHub Actions workflow that the create wizard generated.
2. Find the Build with Maven step and set its command to:

run: mvn clean install -Dquarkus.package.jar.type=uber-jar -DskipTests

-DskipTests skips integration tests because the GitHub-hosted runner can't reach PostgreSQL through the private endpoint. The current Quarkus Maven property is quarkus.package.jar.type.

Step 5:

1. Select the Source Control extension.
2. In the textbox, type a commit message like Configure DB and deployment. Or, select and let GitHub Copilot generate a commit message for you.
3. Select Commit, then confirm with Yes.
4. Select Sync changes 1, then confirm with OK.

Step 6:

1. From the left menu, select Deployment > Deployment Center > Logs.
2. In the log item for the deployment run, select the Build/Deploy Logs entry with the latest timestamp.

Step 7: You're taken to your GitHub repository and see that the GitHub action is running. The workflow file defines separate build and deploy jobs. Wait for the GitHub run to show a status of Success. The deployment and first Java 25 startup can take several minutes.

Having issues? Check the Troubleshooting section.

5. Browse to the app

Step 1: In the App Service page:

1. From the left menu, select Overview.
2. Select the URL of your app.

Step 2: Add a few fruits to the list. Congratulations, you're running a web app in Azure App Service, with secure connectivity to Azure Database for PostgreSQL.

6. Stream diagnostic logs

Azure App Service captures all messages output to the console to help you diagnose issues with your application. The sample application includes standard JBoss logging statements to demonstrate this capability as shown below.

@Consumes("application/json")
public class FruitEntityResource {

    private static final Logger LOGGER = Logger.getLogger(FruitEntityResource.class.getName());

    @GET
    public List<FruitEntity> get() {

Step 1: In the App Service page:

1. From the left menu, select Monitoring > App Service logs.
2. Under Application logging, select File System.
3. In the top menu, select Save.

Step 2: From the left menu, select Log stream. You see the logs for your app, including platform logs and logs from inside the container.

Learn more about logging in Java apps in the series on Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications.

7. Clean up resources

When you're finished, you can delete all of the resources from your Azure subscription by deleting the resource group.

Step 1: In the search bar at the top of the Azure portal:

1. Enter the resource group name.
2. Select the resource group.

Step 2: In the resource group page, select Delete resource group.

Step 3:

1. Enter the resource group name to confirm your deletion.
2. Select Delete.
3. Confirm with Delete again.

:

2. Create Azure resources and deploy a sample app

In this step, you use the AZD files already included on the sample repository's main branch. They create the secure-by-default architecture and deploy the application to App Service on Linux. You don't need to initialize or overlay a separate template.

The dev container already has the Azure Developer CLI (AZD).

1. From the repository root of the GitHub codespace, sign in to Azure:

   azd auth login
   

2. Create an AZD environment. Use a unique environment name of no more than 25 characters. Alphanumeric characters and hyphens are allowed. This limit keeps generated Azure Managed Redis names within cross-region naming limits.

   azd env new <environment-name>
   

3. Preview the infrastructure changes. Follow the prompts to select the subscription and location.

   azd provision --preview
   

   The preview evaluates the infrastructure without creating resources. Review the proposed changes before continuing.

4. Provision the resources and deploy the application:

   azd up
   

   Provisioning and deployment take about 15 minutes. Azure Managed Redis usually takes the longest to provision, and the first Java 25 startup can take a few minutes. The command shows links to the Azure deployment and the deployed application.

The sample's azure.yaml and infra directory create the following resources and configuration:

• Resource group: Contains all created resources.
• App Service plan: Provides the Linux compute resources in the Basic tier.
• App Service: Runs the Quarkus application on Java 25.
• Virtual network: Integrates with App Service and isolates back-end traffic.
• Azure Database for PostgreSQL flexible server 16: Contains the application database and user and is accessible only within the virtual network.
• Azure Managed Redis Balanced_B0: Its default database uses encrypted connections, access-key authentication, and a private endpoint with public network access disabled.
• Key Vault: Stores the PostgreSQL and Azure Managed Redis secrets and is accessible only through its private endpoint.
• Private endpoints and network interfaces: Provide private IP addresses for Key Vault and Azure Managed Redis.
• Private DNS zones: Resolve PostgreSQL, Key Vault, and Azure Managed Redis names within the virtual network.
• Log Analytics workspace: Receives App Service logs and supports log queries.
• Service Connectors: Configure the application connections to PostgreSQL, Azure Managed Redis, and Key Vault.

After deployment, AZD displays these four connector-generated setting names without exposing their secret values:

App Service app has the following connection settings:
        - AZURE_POSTGRESQL_CONNECTIONSTRING
        - AZURE_REDIS_CONNECTIONSTRING
        - AZURE_KEYVAULT_RESOURCEENDPOINT
        - AZURE_KEYVAULT_SCOPE

The template adds these app settings and stores secrets in Key Vault. It also configures JAVA_OPTS with the Java 25 module-opening options. JAVA_OPTS is a runtime setting, not a connection setting, so it isn't included in the preceding list.

The sample already contains its production Quarkus settings. Don't uncomment or add settings after azd up. To deploy later application changes without reprovisioning the infrastructure, run:

azd deploy

Having issues? Check the Troubleshooting section.

3. Browse to the app

1. In the AZD output, find the Endpoint shown after the Deploying service web message and go to it in the browser.

2. Add a few fruits to the list.

   

   Congratulations, you're running a web app in Azure App Service, with secure connectivity to Azure Database for PostgreSQL.

Having issues? Check the Troubleshooting section.

4. Stream diagnostic logs

Azure App Service can capture console logs to help you diagnose issues with your application. For convenience, the AZD template already enables logging to the local file system and is shipping the logs to a Log Analytics workspace.

The sample application includes standard JBoss logging statements to demonstrate this capability as shown below.

@Consumes("application/json")
public class FruitEntityResource {

    private static final Logger LOGGER = Logger.getLogger(FruitEntityResource.class.getName());

    @GET
    public List<FruitEntity> get() {

In the AZD output, find the link to stream App Service logs and navigate to it in the browser. The link looks like this in the AZD output:

Stream App Service logs at: https://portal.azure.com/#@/resource/subscriptions/<subscription-guid>/resourceGroups/<group-name>/providers/Microsoft.Web/sites/<app-name>/logStream

Learn more about logging in Java apps in the series on Enable Azure Monitor OpenTelemetry for .NET, Node.js, Python and Java applications.

Having issues? Check the Troubleshooting section.

5. Clean up resources

To completely delete all Azure resources in the current deployment environment, including purged soft-deleted resources where supported, run azd down --purge and follow the prompts.

azd down --purge

Troubleshooting

The GitHub Actions run failed at the build stage

Select the failed build stage to see which step failed. If it's the Build with Maven stage, expand the step to verify that the -DskipTests option is used. If not, go back to 4. Deploy sample code and modify the GitHub workflow file according to the instructions.

The app failed to start and shows the following error in the log stream: "Model classes are defined for the default persistence unit <default> but configured datasource <default> not found: the default EntityManagerFactory will not be created."

This Quarkus error is most likely because the app can't connect to the Azure database. Make sure that the app setting AZURE_POSTGRESQL_CONNECTIONSTRING hasn't been changed, and that application.properties is using the app setting properly.

The app failed to start and the log stream shows "Waiting for response to warmup request for container"

The first Java 25 startup can take a few minutes, so wait for Quarkus initialization to finish. If warmup continues, the application is probably not configured to listen to the port specified by the App Service PORT environment variable. Go back to 4. Deploy sample code and verify that application.properties contains %prod.quarkus.http.port=${PORT}.

The app failed to start and the log stream shows "module java.base does not open java.lang to unnamed module"

Java 25 requires module-opening options for this application. The AZD template configures the required JAVA_OPTS value automatically. For the Portal workflow, verify that the App Service application setting is present and has this value:

--add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED

After you add or correct the setting, restart the App Service app.

The app reports that the PostgreSQL server version isn't supported

Quarkus 3.38.1 uses Hibernate ORM 7, which requires PostgreSQL 14 or later. This tutorial and its AZD template provision PostgreSQL 16. In the Azure portal, open the flexible server Overview page and verify that PostgreSQL version is 16. If you connected the app to an older server, upgrade or replace that server and update the Service Connector.

The app works, but I see the error log "ERROR [org.acm.hib.orm.pan.ent.FruitEntityResource] (vert.x-eventloop-thread-0) Failed to handle request: jakarta.ws.rs.NotFoundException: HTTP 404 Not Found".

This is a Vert.x error (see Quarkus Reactive Architecture), indicating that the client requested an unknown path. It can happen the first time the app starts, when the client requests the REST API before the Hibernate database migration happens.

In App Service, this error also happens on every app startup because App Service verifies that the app starts by sending a GET request to /robots933456.txt.

Frequently asked questions

• How much does this setup cost?
• How do I connect to the PostgreSQL server that's secured behind the virtual network with other tools?
• How does local app development work with GitHub Actions?
• What if I want to run tests with PostgreSQL during the GitHub workflow?
• I don't have permissions to create a user-assigned identity
• What can I do with GitHub Copilot in my codespace?

How much does this setup cost?

Pricing for the created resources is as follows:

• The App Service plan is created in Basic tier and can be scaled up or down. See App Service pricing.
• The PostgreSQL 16 flexible server is created in the lowest burstable tier Standard_B1ms, with the minimum storage size, and you can scale it up or down. See Azure Database for PostgreSQL pricing.
• The AZD workflow creates Azure Managed Redis with the Balanced_B0 SKU. The portal workflow doesn't create Azure Managed Redis. See Azure Managed Redis pricing.
• The virtual network doesn't incur a charge unless you configure extra functionality, such as peering. See Azure Virtual Network pricing.
• Private endpoints incur hourly and data-processing charges. The portal workflow uses a private endpoint for Key Vault; the AZD workflow also uses one for Azure Managed Redis. See Azure Private Link pricing.
• Private DNS zones incur small charges. The AZD workflow creates zones for PostgreSQL, Key Vault, and Azure Managed Redis. See Azure DNS pricing.
• Key Vault charges for stored keys and secrets and for operations. See Key Vault pricing.
• Log Analytics charges for data ingestion and retention beyond included allowances. See Azure Monitor pricing.

How do I connect to the PostgreSQL server that's secured behind the virtual network with other tools?

• For basic access from a command-line tool, you can run psql from the app's SSH terminal.
• To connect from a desktop tool, your machine must be within the virtual network. For example, it could be an Azure VM that's connected to one of the subnets, or a machine in an on-premises network that has a site-to-site VPN connection with the Azure virtual network.
• You can also use Azure Cloud Shell in a virtual network.

How does local app development work with GitHub Actions?

Using the autogenerated workflow file from App Service as an example, each git push kicks off a new build and deployment run. From a local clone of the GitHub repository, you make the desired updates and push to GitHub. For example:

git add .
git commit -m "<some-message>"
git push origin starter-no-infra

What if I want to run tests with PostgreSQL during the GitHub workflow?

The default Quarkus sample application includes tests with database connectivity. To avoid connection errors, you added the -DskipTests property. If you want, you can run the tests against a PostgreSQL service container. For example, in the automatically generated workflow file in your GitHub fork (.github/workflows/starter-no-infra_<app-name>.yml), make the following changes:

1. Add YAML code for the PostgreSQL container to the build job, as shown in the following snippet.

   ...
   jobs:
     build:
       runs-on: ubuntu-latest
   
       # BEGIN CODE ADDITION
       container: ubuntu
       services:
         # Hostname for the PostgreSQL container
         postgresdb:
                       image: postgres:16
           env:
             POSTGRES_PASSWORD: postgres
             POSTGRES_USER: postgres
             POSTGRES_DB: postgres
           # Set health checks to wait until postgres has started
           options: >-
             --health-cmd pg_isready
             --health-interval 10s
             --health-timeout 5s
             --health-retries 5
   
       # END CODE ADDITION
   
       steps:
         - uses: actions/checkout@v4
         ...
   

   container: ubuntu tells GitHub to run the build job in a container. This way, the connection string in your dev environment jdbc:postgresql://postgresdb:5432/postgres can work as-is in when the workflow runs. For more information about PostgreSQL connectivity in GitHub Actions, see Creating PostgreSQL service containers.

2. In the Build with Maven step, remove -DskipTests. The starter-no-infra branch doesn't preconfigure Uber-Jar packaging, so retain the current Quarkus package property:

         - name: Build with Maven
           run: mvn clean install -Dquarkus.package.jar.type=uber-jar
   

I don't have permissions to create a user-assigned identity

See Set up GitHub Actions deployment from the Deployment Center.

What can I do with GitHub Copilot in my codespace?

You might have noticed that the GitHub Copilot chat view was already there for you when you created the codespace. However, you need a GitHub Copilot account (30-day free trial available).

A few tips for you when you talk to GitHub Copilot:

• In a single chat session, the questions and answers build on each other and you can adjust your questions to fine-tune the answer you get.
• By default, GitHub Copilot doesn't have access to any file in your repository. To ask questions about a file, open the file in the editor first.
• To let GitHub Copilot have access to all of the files in the repository when preparing its answers, begin your question with @workspace. For more information, see Use the @workspace agent.
• In the chat session, GitHub Copilot can suggest changes and (with @workspace) even where to make the changes, but it's not allowed to make the changes for you. It's up to you to add the suggested changes and test it.

Next steps

• Azure for Java Developers
• Quarkus
• Getting Started with Quarkus

Learn more about running Java apps on App Service in the developer guide.

Configure a Java app in Azure App Service

Learn how to secure your app with a custom domain and certificate.

 Secure with custom domain and certificate