Finding Port or Address of Your Application

As you send your application to the cloud, you may want to know what its running port/hostname/ip is, here is a quick guide:

  • The port is an environment variable called app_port (eg System.getenv(“app_port”)). 

  • The hostname can be obtained via the usual means (eg InetAddress.getLocalHost().getHostName())

  • The host name will be the private name - ie it will resolve to a private IP - good for node to node communication. 

  • Public IP/hostname: perform a HTTP get (from the server) to the following URL:http://instance-data/latest/meta-data/public-hostname (will only return the public IP on the server side of course). 

There is an API in the works that will provide cluster membership (allowing you to query for changes) which will hopefully be available shortly (this is handy for building things like akka clusters).


This is wonderful, thank you. I'm currently seeing null for app_port, but the Public IP lookup is working just fine. Example: (scroll, scroll, scroll to the bottom for public IP and port). Source:

Ah yes - bummer. Just realised - that won't be general purpose. For now - you have to dig port out the way you are now.

Update: To get the port, look at the file names in $PWD/.genapp/ports (as applications can have multiple ports) - (eg System.getenv("PWD") + ".genapp/ports" - list the files in that directory - generally will be just 1 - the file name is the port). There are other ways - for example the "" system property on JVM apps too.

Great - I've updated that envdump app to try out those methods, and it's working fine for me. Thanks again.

Thanks Richard - is it ok to point people to your app as an "environment explorer" type of thing? (either the source of the instance of your app) - in the doco?

I'm really missing something here, I can't find the IP address of my app (in order to point the 'A Name' in my domain provider to the app). When using the URL provided "http://instance-data/latest/meta-data/public-hostname" do I have to use that EXACTLY as it is? I've tried it exactly AND as: String hostName = InetAddress.getLocalHost().getHostName(); String urlToRead = "http://instance-data/latest/meta-data/public-hostname/" + hostName; and I've tried String hostName = InetAddress.getLocalHost().getHostName(); String urlToRead = "http://instance-data/latest/meta-data/" + hostName; but I don't know what to do with that 'urlToRead' I've done this (with each of the three types of 'urlToRead' listed above) URL url; HttpURLConnection conn; BufferedReader rd; url = new URL(urlToRead); conn = (HttpURLConnection) url.openConnection(); conn.setRequestMethod("GET"); rd = new BufferedReader(new InputStreamReader(conn.getInputStream())); Where do I get the IP address from??? I know there may be several of you laughing reading this, but I've really no clue what to do with the info on the cloudbees faq. Please help, Thank you.

If you want the IP address that will use for DNS purposes - do NOT use your apps direct address. Look up - using nslookup or similar, and use THAT ip (or use a CNAME) - that is the IP address of the revproxy - which is what all web traffic should go through (putting other ips in DNS won't work - as they will change on you and you probably won't be able to update your DNS fast enough). Can I ask what FAQ you are looking at that confused you?

Checking in on this: has the API for cluster membership been released? Is there any experience/guidance yet with using Akka clustering on CloudBees? My startup is finally getting to Alpha, and it'll soon be time for me to move it into the cloud, so I'm trying to evaluate CloudBees as an option. (If clustering works smoothly, I still consider CloudBees to be the best option I know of, but I'm by no means an expert on the topic myself...)

Justin - there are no features just yet, but you can make your app cluster aware quite easily. The trick is (and I will write this up as another post/article later today): Include the BeesClient library in your app (it is open source and in maven), and run: val client = new BeesClient("", key, secret, "xml", "1.0") client.setVerbose(false)<br /> val instances = client.applicationInstanceList(conf.appId).getInstances() each instance in the list has a "getSettings" method, in that method you can get "host" and "port" - to find the other instance of your app. Obviously, over time, this list can change, so your cluster topography needs to be aware of this. What cluster tech are you using? Things like Akka only need to find one other seed node - then it can discover the rest, for instance.

There's nothing yet -- I've been focused on app functionality to start, and the friends-and-family phase of Alpha is going to be on a single instance -- but the plan is to begin moving towards relatively conventional Akka 2.2 clustering in December. I expect that I'll do the initial experiments on our server (which has two virtual instances already configured), but we obviously need to move to something real and scalable by early next year. (I intentionally held off on clustering until after Akka 2.2 was released, so I could focus on the released system.) Cloudbees is very appealing to us (my CIO would dearly love to avoid having to manage a bunch of raw instances on EC2), so if y'all have successfully gotten Akka clustering working there in a reasonably straightforward way, it'll likely be the primary avenue I pursue. Mind, I'm still a naif when it comes to Akka clustering. I know the broad theory, and have the architecture sketched out, but I'm only now starting to look into the nuts and bolts. So any practical guidance you happen to have, especially on the relationship of Akka clustering and Cloudbees, would be welcomed. I'll likely want to do some experiments in the next month, to make sure I understand how it works before I begin evolving Querki towards it...

Hi Justin - yes Akka clustering can be tricky - I am not sure of people who are doing it right now (people talk about it a lot but I am not sure how many are experienced with it in production). The tricky bit with Akka is that it needs a separate port to run on to the http port. On proposal I was talking about with the Typesafe guys is that there is an app that acts as a co-ordinator (any app can do it) - and all the app instances regularly heartbeat to it - and this app maintains a subset of membership list - Akka only needs to find a seed node - from there it can discover the rest of the cluster by walking the graph. The trick is that this cluster membership can be very dynamic - so how it is setup and coded can have a big impact on how well it works, not easy in the real world I am afraid - but it can be solved!

Hmm. Okay -- let's talk about this in email in more detail, probably in a month or two. (Once I'm more conversant in "standard" Akka Clustering.) I'm willing to do *some* pioneering here, but have to maintain a fairly strict bound on that -- the effect of being a mostly one-man team is that I can't get too distracted onto exploration that isn't directly product-related. It's worthwhile to trade some extra development time to save a lot of IT effort (especially if we can come up with good recipes for other folks to use), but it'll depend on finding reasonable approaches without tons of effort, especially since I'll wind up limited in how assist I can get from Typesafe for it...

Haha - I understand. Well do keep in touch. In the medium term I have some solutions, but longer term the port allocation issue needs to be resolved. I am also toying with the idea of enhancing Play to multiplex Akka/http on the same port.

Add new comment