Skip Navigation
Show nav
Heroku Dev Center
  • Get Started
  • Documentation
  • Changelog
  • Search
  • Get Started
    • Node.js
    • Ruby on Rails
    • Ruby
    • Python
    • Java
    • PHP
    • Go
    • Scala
    • Clojure
  • Documentation
  • Changelog
  • More
    Additional Resources
    • Home
    • Elements
    • Products
    • Pricing
    • Careers
    • Help
    • Status
    • Events
    • Podcasts
    • Compliance Center
    Heroku Blog

    Heroku Blog

    Find out what's new with Heroku on our blog.

    Visit Blog
  • Log inorSign up
View categories

Categories

  • Heroku Architecture
    • Dynos (app containers)
    • Stacks (operating system images)
    • Networking & DNS
    • Platform Policies
    • Platform Principles
  • Command Line
  • Deployment
    • Deploying with Git
    • Deploying with Docker
    • Deployment Integrations
  • Continuous Delivery
    • Continuous Integration
  • Language Support
    • Node.js
    • Ruby
      • Working with Bundler
      • Rails Support
    • Python
      • Working with Django
      • Background Jobs in Python
    • Java
      • Working with Maven
      • Java Database Operations
      • Working with the Play Framework
      • Java Advanced Topics
      • Working with Spring Boot
    • PHP
    • Go
      • Go Dependency Management
    • Scala
    • Clojure
  • Databases & Data Management
    • Heroku Postgres
      • Postgres Basics
      • Postgres Performance
      • Postgres Data Transfer & Preservation
      • Postgres Availability
      • Postgres Special Topics
    • Heroku Redis
    • Apache Kafka on Heroku
    • Other Data Stores
  • Monitoring & Metrics
    • Logging
  • App Performance
  • Add-ons
    • All Add-ons
  • Collaboration
  • Security
    • App Security
    • Identities & Authentication
    • Compliance
  • Heroku Enterprise
    • Private Spaces
      • Infrastructure Networking
    • Enterprise Accounts
    • Enterprise Teams
    • Heroku Connect (Salesforce sync)
    • Single Sign-on (SSO)
  • Patterns & Best Practices
  • Extending Heroku
    • Platform API
    • App Webhooks
    • Heroku Labs
    • Building Add-ons
      • Add-on Development Tasks
      • Add-on APIs
      • Add-on Guidelines & Requirements
    • Building CLI Plugins
    • Developing Buildpacks
    • Dev Center
  • Accounts & Billing
  • Troubleshooting & Support
  • Language Support
  • Java
  • Setting the HTTP Port for Java Applications

Setting the HTTP Port for Java Applications

English — 日本語に切り替える

Last updated April 09, 2020

Table of Contents

  • Spring Boot
  • Webapp Runner (Tomcat)
  • Play Framework
  • Dropwizard
  • Thorntail
  • Ratpack
  • Grails

Heroku expects a web application to bind its HTTP server to the port defined by the $PORT environment variable. Many frameworks default to port 8080, but can be configured to use an environment variable instead. In most cases, the port can be configured by adding a parameter to the java command in an application’s Procfile, but some frameworks provide a configuration file. The most common Java frameworks are listed here.

Spring Boot

Spring-Boot provides a few different mechanisms for setting the HTTP port. It can be passed an option to the executable JAR file (i.e. the options after the -jar app.jar options in your java command):

--server.port=$PORT

Or as a Java system property:

-Dserver.port=$PORT

In both cases, these options can be added to the java command in an app’s Procfile. Another option is a configuration element in the application.yml:

server:
    port: $PORT

For more info see Spring Boot documentation on Properties and Configuration

Webapp Runner (Tomcat)

Webapp Runner allows you to launch an exploded or compressed war on your filesystem into a Tomcat container with a simple java -jar command. It accepts the following option to the executable JAR file (i.e. the options after the -jar webapp-runner.jar options in your java command):

--port $PORT

When using the heroku war:deploy and Heroku Maven Plugin tools, this option is configured for you. For more information, see the Webapp Runner documentation.

Play Framework

The Play Framework, which uses Netty as its server, accepts a Java system property (i.e. an option to the java command):

-Dhttp.port=$PORT

For more info see the Play documentation for Heroku.

Dropwizard

The Dropwizard framework accepts a Java system property:

-Ddw.server.applicationConnectors[0].port=$PORT

For more information see the Dropwizard Configuration reference.

Thorntail

The Thorntail framework accepts a system property:

-Dswarm.http.port=$PORT

For more information see the WildFly Swarm documentation.

Ratpack

The Ratpack framework, which uses the Netty server, automatically detects the $PORT environment variable and configures the app to use it.

Grails

The Grails 3 framework produces a WAR file that can be run with either Tomcat or Jetty. See the Webapp Runner section for more information.

For more information see the WildFly Swarm

Keep reading

  • Java

Feedback

Log in to submit feedback.

Information & Support

  • Getting Started
  • Documentation
  • Changelog
  • Compliance Center
  • Training & Education
  • Blog
  • Podcasts
  • Support Channels
  • Status

Language Reference

  • Node.js
  • Ruby
  • Java
  • PHP
  • Python
  • Go
  • Scala
  • Clojure

Other Resources

  • Careers
  • Elements
  • Products
  • Pricing

Subscribe to our monthly newsletter

Your email address:

  • RSS
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku Blog
    • Heroku News Blog
    • Heroku Engineering Blog
  • Heroku Podcasts
  • Twitter
    • Dev Center Articles
    • Dev Center Changelog
    • Heroku
    • Heroku Status
  • Facebook
  • Instagram
  • Github
  • LinkedIn
  • YouTube
Heroku is acompany

 © Salesforce.com

  • heroku.com
  • Terms of Service
  • Privacy
  • Cookies