My two cents about software development on the web

Cloud Platforms

Warning: file_put_contents(C:\hostingspaces\neetpiqc\\wwwroot/wp-content/cache/0bac12a71080e2f0238f1b173488ab6f.spc) [function.file-put-contents]: failed to open stream: Permission denied in C:\hostingspaces\neetpiqc\\wwwroot\wp-includes\class-simplepie.php on line 8680

Warning: C:\hostingspaces\neetpiqc\\wwwroot/wp-content/cache is not writeable. Make sure you've set the correct relative or absolute path, and that the location is server-writable. in C:\hostingspaces\neetpiqc\\wwwroot\wp-includes\class-simplepie.php on line 1781

Warning: file_put_contents(C:\hostingspaces\neetpiqc\\wwwroot/wp-content/cache/ad31bb8bf02bbf58903d4663ca4ee574.spc) [function.file-put-contents]: failed to open stream: Permission denied in C:\hostingspaces\neetpiqc\\wwwroot\wp-includes\class-simplepie.php on line 8680

Warning: C:\hostingspaces\neetpiqc\\wwwroot/wp-content/cache is not writeable. Make sure you've set the correct relative or absolute path, and that the location is server-writable. in C:\hostingspaces\neetpiqc\\wwwroot\wp-includes\class-simplepie.php on line 1781
  • Windows Server 2012 R2, IIS 8.5, WebSockets and .NET 4.5.2 (AppHarbor Blog)

    During the last couple of weeks we've upgraded worker servers in the US and EU regions to support Windows Server 2012 R2, IIS 8.5 and .NET 4.5.2. Major upgrades like this can be a risky and lead to compatibility issues, and the upgrade was carefully planned and executed to maximize compatibility with running applications. Application performance and error rates have been closely monitored throughout the process and fortunately, chances are you haven't noticed a thing: We've detected migration-related issues with less than 0.1% of running applications.

    Many of the new features and configuration improvements enabled by this upgrade will be gradually introduced over the coming months. This way we can ensure a continued painless migration and maintain compatibility with the previous Windows Server 2008 R2/IIS 7.5 setup, while we iron out any unexpected kinks if and when they crop up. A few changes have however already been deployed that we wanted to fill you in on.

    WebSocket support and the beta region

    Last year the beta region featuring experimental WS2012 and WebSockets support was introduced. The beta region allowed customers to test existing and new apps on the new setup while we prepared and optimized it for production use. This approach has been an important factor in learning about subtle differences between the server versions, and addressing pretty much all compatibility issues before upgrading the production regions. Thanks to all the customers who provided valuable feedback during the beta and helped ensure a smoother transition for everyone.

    An important reason for the server upgrade was to support WebSocket connections. Now that the worker servers are running WS2012 and IIS 8.5 we've started doing just that. Applications in the old beta region have been merged into the production US region and the beta region is no longer available when you create a new application.

    Most load balancers already support WebSockets and the upgrade is currently being rolled out to remaining load balancers. Apps created since August 14th fully support WebSockets and no configuration is necessary: AppHarbor will simply detect and proxy connections as expected when a client requests a Connection: Upgrade.

    Some libraries, such as SignalR, will automatically detect and prefer WebSocket connections when supported by both the server and client. Until WebSocket connections are supported on all load balancers some apps may attempt and fail during the WebSocket handshake. This should not cause issues since these libraries will fall back to other supported transports, and affected apps will automatically be WebSocket-enabled when supported by the load balancers.

    CPU throttling

    One of the major challenges that has held back this upgrade is a change in the way we throttle worker CPU usage. CPU limitations are the same as before, but the change can affect how certain CPU-intensive tasks are executed. Resources and documentation on this subject are limited, but testing shows that CPU time is more evenly scheduled across threads, leading to higher concurrency, consistency and stability within processes. While this is overall an improvement it can also affect peak performance on individual threads, and we're currently investigating various approaches to better support workloads affected by this.

    For the curious, we previously used a CPU rate limit registry setting to limit CPU usage per user account, but this is no longer supported on Windows Server 2012. We now use a combination of IIS 8's built-in CPU throttling and a new CPU rate control for job objects to throttle background workers.

    If you've experienced any issues with this upgrade or have feedback about the process, please don't hesitate to reach out.

  • Heartbleed Security Update (AppHarbor Blog)

    Updated on April 10, 2014 with further precautionary steps in the "What can you do" section below.

    On April 7, 2014, a serious vulnerability in the OpenSSL library (CVE-2014-0160) was publicly disclosed. OpenSSL is a cryptography library used for the majority of private communications across the internet.

    The vulnerability, nicknamed "Heartbleed", would allow an attacker to steal secret certificates keys, names and passwords of users and other secrets encrypted using the OpenSSL library. As such it represents a major risk for a large number of internet application and services, including AppHarbor.

    What has AppHarbor done about this

    AppHarbor responded to the announcement by immediately taking steps to remediate the vulnerability:

    1. We updated all affected components with the updated, secure version of OpenSSL within the first few hours of the announcement. This included SSL endpoints and load balancers, as well as other infrastructure components used internally at AppHarbor.
    2. We re-keyed and redeployed all potentially affected AppHarbor SSL certificates (including the piggyback * certificate), and the old certificates are being revoked.
    3. We notified customers with custom SSL certificates last night, so they could take steps to re-key and reissue certificates, and have the old ones revoked.
    4. We reset internal credentials and passwords.
    5. User session cookies were revoked, requiring all users to sign in again.

    Furthermore, AppHarbor validates session cookies against your previously known IP addresses as part of the authorization process. This has reduced the risk of a stolen session cookie being abused. Perfect forward secrecy was deployed to some load balancers, making it impossible to read intercepted and encrypted communication with stolen keys. Forward secrecy has since been deployed to all load balancers hosted by AppHarbor.

    What can you do

    We have found no indication that the vulnerability was used to attack AppHarbor. By quickly responding to the issue and taking the steps mentioned above we effectively stopped any further risk of exposure. However, due to the nature of this bug, we recommend users who want to be extra cautious to take the following steps:

    1. Reset your AppHarbor password.
    2. Review the sign-in and activity history on your user page for any suspicious activity.
    3. Revoke authorizations for external applications that integrates with AppHarbor.
    4. Recreate, reissue and reinstall custom SSL certificates you may have installed, and revoke the old ones. Doing this may revoke the old certificates, so make sure you're ready to install the new certificates.
    5. Read the details about the Heartbleed bug here and assess the risks relative to your content.

    Updated instructions (April 10, 2014):

    While we still have not seen any abuse on AppHarbor as a result of this bug, we now also encourage you to take these precautionary steps:

    1. Reset your build URL token.
    2. If you're using one of the SQL Server or MySQL add-ons: Reset the database password. Go to the add-on's admin page and click the "Reset Password" button. This will immediately update the configuration on AppHarbor and redeploy the application (with a short period of downtime until it is redeployed).
    3. If you're using the Memcacher add-on: Reinstall the add-on by uninstalling and installing it.
    4. Rotate/update sensitive information in your own configuration variables.

    If you have hardcoded passwords/connection strings for any your add-ons this is a good opportunity to start using the injected configuration variables. You can find instructions for the SQL add-ons here and the Memcacher add-on here. This way your application is automatically updated when you reset the add-ons, or when an add-on provider updates the configuration. If this is not an option you should immediately update your code/configuration files and redeploy the application after the configuration is updated.

    Stay tuned

    Protecting your code and data is our top priority, and we continue to remediate and asses the risks in response to this issue. We'll keep you posted with any new developments, so stay tuned on Twitter and the blog for important updates. We're of course also standing by on the support forums if you have any questions or concerns.

  • Librato integration and built-in perfomance metrics (AppHarbor Blog)

    Librato Dashboard

    Being able to monitor and analyze key application metrics is an essential part of developing stable, performant and high quality web services that meets you business requirements. Today we’re announcing a great new set of features to provide a turnkey solution for visualizing, analyzing and acting on key performance metrics. On top of that we’re enabling you to easily track your own operational metrics. In this blog post we’ll look at how the pieces tie together.

    Librato integration

    The best part of today’s release is our new integration with Librato for monitoring and analyzing metrics. Librato is an awesome and incredibly useful service that enables you to easily visualize and correlate metrics, including the new log-based performance metrics provided by AppHarbor (described in more details below).

    Librato Dashboard

    Librato is now available as an add-on and integrates seamlessly with your AppHarbor logs. When you provision the add-on, Librato will setup a preconfigured dashboard tailored for displaying AppHarbor performance data and you can access it immediately by going to the Librato admin page. Everything will work out of the box without any further configuration and your logs will automatically be sent to Librato using a log drain.

    When log messages containing metric data are sent to Librato they’re transformed by an l2met service before being sent to their regular API. A very cool feature of the l2met service is that it can automatically calculate some useful metrics. For instance, it’ll calculate the median response time as well as the the 99th and 95th percentile of measurements such as response times. The perc99 response time means the response time of the 99% fastest responses. It can be useful to know this value since it's less affected by a few very slow responses than the average. Among other things this provides a good measurement of the browsing experience for most of your users.

    Librato Dashboard

    The l2met project was started by Ryan Smith - a big shout-out and thanks to him and the Librato team for developing this great tool.

    For more information about how to integrate with Librato and details about the service please refer to the documentation here. Also check out their announcement blog post about the integration.

    Built-in performance metrics

    AppHarbor can now write key runtime performance metrics directly to your application’s log stream as l2met 2.0 formatted messages similar to this:

    source=web.5 sample#memory.private_bytes=701091840
    source=web.5 sample#process.handles=2597
    source=web.5 sample#cpu.load_average=1.97

    These are the messages Librato uses as well and most of them are written every 20 seconds. They allow for real-time monitoring of worker-specific runtime metrics such as CPU (load average) and memory usage, as well as measurements of response time and size reported from the load balancers. Because these metrics are logged to your log stream you can also consume them in the same way you’d usually view or integrate with your logs.

    Load average run-time metrics

    Performance data collection takes place completely out-of-process, without using a profiler, and it can be enabled and disabled without redeploying the application. This means that monitoring won’t impact application performance at all and that a profiler (such as New Relic) can still be attached to the application.

    Writing custom metrics

    The performance data provided by AppHarbor is probably not the only metrics you want to track. You can of course integrate directly with Librato’s API, but the l2met integration makes it easier than ever to track your own metrics, and the paid Librato plans includes the ability to track custom metrics exactly for that purpose.

    You can start writing your own metrics simply by sending an l2met-formatted string to your logs. Last week we introduced the Trace Logging feature which is perfect for this, so writing your custom metrics can now be done with a simple trace:


    To make this even easier we’ve built the metric-reporter library (a .NET port of Librato’s log-reporter) to provide an easy to use interface for writing metrics to your log stream. You can install it with NuGet:

    Install-Package MetricReporter

    Then initialize a MetricReporter which writes to a text writer:

    var writer = new L2MetWriter(new TraceTextWriter);
    var reporter = new MetricReporter(metricWriter);

    And start tracking your own custom metrics:

    reporter.Measure("payload.size", 21276);
    reporter.Measure("twitter.lookup.time", () =>
        //Do work

    On Librato you can then view charts with these new metrics along with the performance metrics provided by AppHarbor, and add them to your dashboards, aggregate and correlate data, set up alerts etc. The MetricReporter library will take care of writing l2met-formatted metrics using the appropriate metric types and write to the trace or another IO stream. Make sure to inspect the README for more examples and information on configuration and usage.

    That’s all we have for today. There’ll be more examples on how you can use these new features soon, but for now we encourage you to take it for a spin, install the Librato add-on and test the waters for yourself. We’d love to hear what you think so if there are other metrics you’d like to see or if you experience any issues please hit us up through the usual channels.

  • Introducing Trace Logging (AppHarbor Blog)

    Today we’re happy to introduce trace message integration with your application log. With tracing you can very easily log trace messages to your application's log stream by using the built-in tracing capabilities of the .NET framework from anywhere in your application.

    When introducing the realtime logging module a while back we opened up access to collated log data from load balancers, the build and deploy infrastructure, background workers and more. Notably missing however was the ability to log from web workers. We’re closing that gap with tracing, which can be used in both background and web workers.

    How to use it

    The trace feature integrates with standard .NET tracing, so you don’t have to make any changes to your application to use it. You can simply log traces from your workers with the System.Diagnostics.Trace class:

    Trace.TraceInformation("Hello world");

    This will yield a log message containing a timestamp and the source of the trace in your application’s log like so:

    2014-01-22T06:46:48.086+00:00 app web.1 Hello World

    You can also use a TraceSource by specifying the trace source name AppHarborTraceSource:

    var traceSource = new TraceSource("AppHarborTraceSource", defaultLevel: SourceLevels.All);
    traceSource.TraceEvent(TraceEventType.Critical, 0, "Foo");

    You may not always want noisy trace messages in your logs and you can configure the trace level on the "Logging" page. There are 4 levels: All, Warning, Error and None. Setting the trace level will update the configuration without redeploying or restarting the application. This is often desirable if you need to turn on tracing when debugging and diagnosing an ongoing or state-related issue.

    Configure Trace level

    There are a number of other ways to use the new tracing feature including:

    • ASP.NET health monitoring (for logging exceptions, application lifecycle events etc).
    • A logging library such as NLog (Trace target) or log4net (TraceAppender).
    • Integrating with ETW (Event Tracing for Windows) directly using the injected event provider id.

    Anything that integrates with .NET tracing or ETW should work, and you can find more details and examples in this knowledge base article.

    All new applications have tracing enabled by default. Tracing can be enabled for existing applications on the "Logging" page.

    How does it work

    Under the hood we’re using ETW for delivering log messages to the components that are responsible for sending traces to your log stream. Application performance is unaffected by the delivery of log messages as this takes place completely out of process. Note however that messages are buffered for about a second and that some messages may be dropped if you’re writing excessively to the trace output.

    When tracing is enabled, AppHarbor configures your application with an EventProviderTraceListener as a default trace listener. While you can integrate directly with ETW as well we recommend using the Trace or TraceSource approaches described above.

    Viewing trace messages

    Traces are collated with other logging sources in your log stream, so you can consume them in the same way you’re used to. You can view log messages using the command line interface, the web viewer or set up a log drain to any HTTP, HTTPS or syslog endpoint. For more information about the various integration points please refer to this article.

    Viewing trace messages in console

    We’ve got a couple of cool features that builds on this ready soon, so stay tuned and happy tracing!

  • .NET 4.5.1 is ready (AppHarbor Blog)

    Microsoft released .NET 4.5.1 a while back, bringing a bunch of performance improvements and new features to the framework. Check out the announcement for the details.

    Over the past few weeks we have updated our build infrastructure and application servers to support this release. We're happy to report that AppHarbor now supports building, testing and running applications targeting the .NET 4.5.1 framework, as well as solutions created with Visual Studio 2013 and ASP.NET MVC 5 applications.

    There are no known issues related to this release. If you encounter problems, please refer to the usual support channels and we'll help you out.

    .NET logo

  • Integrated NuGet Package Restore (AppHarbor Blog)

    A few months ago the NuGet team released NuGet 2.7, which introduced a new approach to package restore. We recently updated the AppHarbor build process to adopt this approach and integrate the new NuGet restore command. AppHarbor will now automatically invoke package restore before building your solution.

    Automatically restoring packages is a recommended practice, especially because you don’t have to commit the packages to your repository and can keep the footprint small. Until now we’ve recommended using the approach desribed in this blog post to restore NuGet packages when building your application. This has worked relatively well, but it’s also a bit of a hack and has a few caveats:

    • Some NuGet packages rely files that needs to be present and imported when MSBuild is invoked. This has most notably been an issue for applications relying on the Microsoft.Bcl.Build package for the reasons outlined in this article.
    • NuGet.exe has to be committed and maintained with the repository and project and solution files needs to be configured.
    • Package restore can intermittently fail in some cases when multiple projects are built concurrently.

    With this release we expect to eliminate these issues and provide a more stable, efficient and streamlined way of handling package restore.

    If necessary, NuGet can be configured by adding a NuGet.config file in the same directory as your solution file (or alternatively in a .nuget folder under your solution directory). You usually don't have to configure anything if you’re only using the official NuGet feed, but you’ll need to configure your application if it relies on other package sources. You can find an example configuration file which adds a private package source in the knowledge base article about package restore and further documentation for NuGet configuration files can be found here.

    If you hit any snags we’re always happy to help on our support forums.

    NuGet logo

  • New Relic Improves Service and Reduces Price (AppHarbor Blog)

    New Relic

    We're happy to announce that New Relic has dropped the price of the Professional add-on plan from $45/month to $19/month per worker unit. Over the years New Relic has proven to be a really useful tool for many of our customers, and we're pleased that this price drop will make the features of New Relic Professional more accessible to everyone using AppHarbor.

    Highlights of the Professional plan include:

    • Unlimited data retention
    • Real User Monitoring (RUM) and browser transaction tracing
    • Application transaction tracing, including Key Transactions and Cross Application Tracing
    • Advanced SQL and slow SQL analysis

    You can find more information about the benefits of New Relic Pro on the New Relic website (

    Service update

    The New Relic agent was recently upgraded to a newer version which brings support for some recently introduced features as well as a bunch of bug fixes. Time spent in the request queue is now reported and exposed directly in the New Relic interface. Requests are rarely queued for longer than a few milliseconds, but it can happen if your workers are under load. When more time is spent in the request queue it may be an indicator that you need to scale your application to handle the load efficiently.

    We're also making a few changes to the way the New Relic profiler is initialized with your applications. This is particularly relevant if you've subscribed to New Relic directly rather than installing the add-on through AppHarbor. Going forward you'll need to add a NewRelic.LicenseKey configuration variable to make sure the profiler is attached to your application. We recommend that you make this change as soon as possible. If you're subscribed to the add-on through AppHarbor no action is required and the service will continue to work as usual.

  • Found Elasticsearch add-on available (AppHarbor Blog)

    Found ElasticSearch

    Found provides fully hosted and managed Elasticsearch clusters; each cluster has reserved memory and storage ensuring predictable performance. The HTTPS API is developer-friendly and existing Elasticsearch libraries such as NEST, Tire, PyES and others work out of the box. The Elasticsearch API is unmodified, so for those with an existing Elasticsearch integration it is easy to get started.

    For production and mission critical environments customers can opt for replication and automatic failover to a secondary site, protecting the cluster against unplanned downtime. Security has a strong focus: communication to and from the service is securely transmitted over HTTPS (SSL) and data is stored behind multiple firewalls and proxies. Clusters run in isolated containers (LXC) and customisable ACLs allow for restricting access to trusted people and hosts.

    In the event of a datacenter failure, search clusters are automatically failed over to a working datacenter or, in case of a catastrophic event, completely rebuilt from backup.

    Co-founder Alex Brasetvik says: "Found provides a solution for companies who are keen to use Elasticsearch but not overly keen to spend their time and money on herding servers! We provide our customers with complete cluster control: they can scale their clusters up or down at any time, according to their immediate needs. It's effortless and there's zero downtime."

    More information and price plans are available on the add-on page.

  • Introducing Realtime Logging (AppHarbor Blog)

    Today we're incredibly excited to announce the public beta of our brand new logging module. Starting immediately all new applications created on AppHarbor will have logging enabled. You can enable it for your existing apps on the new "Logging" page.

    We know all too well that running applications on a PaaS like AppHarbor sometimes can feel like a black box. So far we haven't had a unified, simple and efficient way to collate, present and distribute log events from the platform and your apps.

    That's exactly what we wanted to address with our logging solution, and based on the amazing feedback from private beta users we feel confident that you'll find it useful for getting insight about your application and AppHarbor. A big thanks to all the beta testers who have helped us refine and test these new features.

    The new logging module collates log messages from multiple sources, including almost all AppHarbor infrastructure component and your applications - API changes, load balancer request logs, build, deploy and stdout/stderr from your background workers and more can now be accessed and sent to external services in real time.

    Captain's log Consider yourself lucky we're not that much into skeuomorphism


    We're providing two interfaces "out of the box" - a convenient web-interface can be accessed on the Logging page and a new log command has been added to the CLI. [Get the installer directly from here or install with Chocolatey cinst appharborcli.install. To start a "tailing" log session with the CLI, you can for instance run appharbor log -t -s appharbor. Type appharbor log -h to see all options. Log web interface

    The web interface works a bit differently, but try it out and let us know what you think - it's heavily inspired by the project who have built a great client side interface for viewing, filtering, searching and splitting logs into multiple "screens".

    Log web interface


    One of the most useful and interesting aspects of today's release is the flexible integration points it provides. Providing access to your logs in realtime is one thing, but AppHarbor will only store the last 1500 log messages for your application. Storing, searching, viewing and indexing logs can be fairly complex and luckily many services already exists that helps you make more sense of your log data.

    We've worked with Logentries to provide a completely automated and convenient way for sending AppHarbor logs to them when you add their add-on. When you add the Logentries add-on your application can automatically be configured to send logs to Logentries, and Logentries will be configured to display log messages in AppHarbor's format.

    Logentries integration

    You can also configure any syslog (TCP), HTTP and HTTPS endpoint you like with log "drains". You can use this to integrate with services like Loggly and Splunk, or even your own syslog server or HTTP service. More details about log drains are available in the this knowledge base article and the drain API documentation.

    Finally there's a new new Log session API endpoint that you can use to create sessions similar to the ones used by the interfaces we provide.


    If you've ever used Heroku you'll find most of these features very familiar. That's no coincidence - the backend is based on Heroku's awesome distributed syslog router, Logplex. Integrating with Logplex makes it a lot easier for add-on providers who already support Heroku's Logplex to integrate with AppHarbor, while giving us a scalable and proven logging backend to support thousands of deployed apps.

    Logplex is also in rapid, active development, and a big shout-out to the awesome people at Heroku who are building this incredibly elegant solution. If you're interested in learning more about Logplex we encourage you to check out the project on Github and try it for yourself. We've built a client library for interacting with Logplex's HTTP API and HTTP log endpoints from .NET apps - let us know if you'd like to use this and we'll be happy to open source the code. The Logplex documentation on stream management is also useful for a high-level overview of how Logplex works.

    Next steps

    With this release we've greatly improved the logging experience for our customers. We're releasing this public beta since we know it'll be useful to many of you as it is, but we're by no means finished. We want to add even more log sources, provide more information from the various infrastructure components and integrate with more add-on providers. Also note that request logs are currently only available on shared load balancers, but it will be rolled out to all load balancers soon. If you find yourself wanting some log data that is not currently available please let us know. We now have a solid foundation to provide you with the information you need when you need it, and we couldn't be more excited about that.

    We'll provide you with some examples and more documentation for these new features over the next couple of weeks, but for now we hope you'll take it for a spin and test the waters for yourself. Have fun!

  • Introducing PageSpeed optimizations (AppHarbor Blog)

    Today we've introducing a new experimental feature: Google PageSpeed optimizations support. The PageSpeed module is a suite of tools that tries to optimize web page latency and bandwidth usage of your websites by rewriting your content to implement web performance best practices. Reducing the number of requests to a single domain, optimizing cache policies and compressing content can significantly improve web performance and lead to a better user experience.

    With PageSpeed optimization filters we're making it easier to apply some of these best practices, and provide a solution that efficiently and effortlessly speed up your web apps. The optimizations takes place at the load balancer level and works for all web applications no matter what framework or language you use.

    As an example of how this works you can inspect the HTML and resources of this blog to see some of the optimizations that are applied. Analyzing with the online PageSpeed insights tool yields a "PageSpeed score" of 88 when enabled versus 73 when disabled. Not too bad considering it only took a click to enable it.

    PageSpeed button

    You can enable PageSpeed optimizations for your web application on the new "Labs" page, which can be found in the application navigation bar. The application will be configured with PageSpeed's core set of filters within a few seconds. We will then, among other things, apply these filters to your content:

    When you've enabled PageSpeed we recommend that you test the application to make sure it doesn't break anything. You can also inspect the returned content in your browser and if you hit any snags simply disable PageSpeed and let support know about it. Note that only content transferred over HTTP from your domain will be processed by PageSpeed filters. To optimize HTTPS traffic you can enable SPDY support (although that is currently only enabled on dedicated load balancers and in the beta region).

    We'll make more filters available later on, but for the beta we're starting out with a curated set of core filters, which are considered safe for most web applications. There are a few other cool filters we'll add support for later on - such as automatic sprite image generation and lazy-loading of images. Let us know if there are any filters in the catalog you think we should support!

  • PostgreSQL 10 Generally Available on Heroku (Heroku)
    14 Dec 2017 16:49

    Today, we're happy to announce full support for PostgreSQL 10, opening our managed Postgres solution to the full slate of features released after a successful two-month Beta period. PostgreSQL 10 is now the default version for all new provisioned Heroku Postgres databases. All Postgres extensions, tooling, and integration with the Heroku developer experience are ready to use, giving you the power of PostgreSQL 10 with the ease and usability of Heroku for building data-centric applications.

    We'd like to re-emphasize a few features - among the many released in Postgres 10 - that we are particularly excited about.

    Native Table Partitioning

    A pattern we often see in databases in our fleet is one or two tables growing at a rate that’s much larger and faster than the rest of the tables in the database. Query times within the application will start to rise, bulk loads will take longer, and creating indexes can take a long time. Postgres table partitioning can be a great way to keep good query performance for those very large tables by partitioning what is logically one big table into smaller physical pieces.

    In PostgreSQL 10, users have the option to leverage native table partitioning — our Postgres 10 beta blog post provides an example on how to use native table partitioning. The pg_partman extension is still supported for those wishing to continue using it for time-based and serial-based table partition sets.

    Increased Parallelism for Performance Improvements

    Additionally, a lot of work in PostgreSQL 10 has been put in to improving use of parallelism for joins, scans and queries. This enables PostgreSQL to take advantage of the multiple CPU cores available on our production plans. Users will see a performance boost for some queries, particularly more complex ones.

    Get Started Today

    If you want to try out the new version, it's is as simple as provisioning a new database:

    $ heroku addons:create heroku-postgresql -a sushi
    $ heroku pg:info DATABASE_URL -a sushi
    Plan:                  Hobby-dev
    Status:                Available
    PG Version:            10.1

    If you have an existing database on the platform, we encourage you to look into upgrading your Postgres version: see our documentation for upgrading. For further details about other new features in PostgreSQL 10, please see the PostgreSQL documentation. Let us know what you think at

  • Jekyll on Heroku (Heroku)
    13 Dec 2017 17:07

    Jekyll, the static website generator written in Ruby and popularized by GitHub, is a great candidate for being run on Heroku. Originally built to run on GitHub Pages, running Jekyll on Heroku allows you to take advantage of Jekyll’s powerful plugin system to do more than convert Markdown to HTML. On my blog, I have plugins to download my Goodreads current and recently read books and to generate Open Graph images for posts. That said, it’s not straightforward to get up and running on Heroku without using jekyll serve to do the heavy lifting. jekyll serve uses Ruby’s built-in, single threaded web server WEBrick, but a public site should be using a web server more suited for production, like nginx.

    We’ll start from the very beginning. You’ll need Ruby and Bundler installed.

    I like ruby-install and chruby as my Ruby installer and switcher.

    This is the platform-agnostic way of installing the latest version of ruby-install. If you prefer, you can find instructions for OS X and Windows in ruby-install’s README.

    The commands below use the most recent versions of ruby-install and chruby available when this post was published. You probably want to use more recent versions if available.

    $ wget -O ruby-install-0.6.1.tar.gz
    $ tar -xzvf ruby-install-0.6.1.tar.gz
    $ cd ruby-install-0.6.1/
    $ sudo make install

    You’ll also want chruby, which you can similarly install in a more platform specific way using instructions in chruby’s README.

    $ wget -O chruby-0.3.9.tar.gz
    $ tar -xzvf chruby-0.3.9.tar.gz
    $ cd chruby-0.3.9/
    $ sudo make install

    Install the latest Ruby and use it:

    $ ruby-install ruby
    $ chruby ruby

    You’ll need Bundler and the Jekyll gem:

    $ gem install bundler jekyll
    Fetching: bundler-1.9.9.gem (100%)
    Successfully installed bundler-1.9.9
    Fetching: jekyll-3.6.2.gem (100%)
    Successfully installed jekyll-3.6.2
    2 gems installed

    Generating a new jekyll site is straightforward, and you get a site template for free similar to starting a new Rails app. We’ll be saving our work in Git along the way:

    $ jekyll new jekyll-on-heroku
    Ignoring nokogiri-1.8.1 because its extensions are not built.  Try: gem pristine nokogiri --version 1.8.1
    Running bundle install in /Users/caleb.thompson/code/jekyll-on-heroku/_rundoc/tmp/jekyll-on-heroku...
    New jekyll site installed in /Users/caleb.thompson/code/jekyll-on-heroku/_rundoc/tmp/jekyll-on-heroku.
    $ cd jekyll-on-heroku
    $ git init
    Initialized empty Git repository in /Users/caleb.thompson/code/jekyll-on-heroku/_rundoc/tmp/jekyll-on-heroku/.git/
    $ git add .
    $ git commit -m "jekyll new jekyll-on-heroku"
    [master (root-commit) ea8cd80] jekyll new jekyll-on-heroku
     8 files changed, 206 insertions(+)
     create mode 100644 .gitignore
     create mode 100644 404.html
     create mode 100644 Gemfile
     create mode 100644 Gemfile.lock
     create mode 100644 _config.yml
     create mode 100644 _posts/2017-12-07-welcome-to-jekyll.markdown
     create mode 100644
     create mode 100644

    We have our Jekyll site (go ahead and try jekyll serve if you’d like), but we’ll need a Heroku app to deploy to. You will need an account and the CLI installed before this step. We’re going to use the official Ruby buildpack as well as Heroku’s (unofficial) Static buildpack to do the site generation and static page serving, respectively:

    $ heroku create
    Creating app... done, radiant-bastion-50307 |
    $ heroku buildpacks:add heroku/ruby
    Buildpack added. Next release on radiant-bastion-50307 will use heroku/ruby.
    Run git push heroku master to create a new release using this buildpack.
    $ heroku buildpacks:add
    Buildpack added. Next release on radiant-bastion-50307 will use:
      1. heroku/ruby
    Run git push heroku master to create a new release using these buildpacks.

    Heroku’s buildpacks need specific files to be present to work correctly. We already have Gemfile for the Ruby buildpack, but we’ll also need a static.json file for the static buildpack. I’ve added a few of my favorite options to the static.json, and we’ll need to use _site/ for our root as that is where Jekyll builds its static content by default.

    In file static.json write:

      "clean_urls": true,
      "https_only": true,
      "root": "_site/"

    Let’s save our progress again.

    $ git add static.json
    $ git commit -m "Add static.json with reasonable defaults"
    [master 6e1dea7] Add static.json with reasonable defaults
     1 file changed, 5 insertions(+)
     create mode 100644 static.json

    The Ruby buildpack runs rake assets:precompile when it’s available. This is inspired by Rails’ pattern, but it works for any assets you’ll need. We’re going to use it for our entire site by running jekyll build.

    In file Rakefile write:

    task "assets:precompile" do
      exec("jekyll build")

    You’ll need Rake to run this in the first place, and we can save ourselves trouble in the future by specifying a version.

    At the end of Gemfile add:

    gem "rake"
    ruby "2.4.2"

    And run bundle to install Rake.

    $ bundle
    Bundle complete! 5 Gemfile dependencies, 24 gems now installed.
    Use `bundle info [gemname]` to see where a bundled gem is installed.

    We need to add the changes for the Rake task and new dependencies:

    $ git add Rakefile Gemfile Gemfile.lock
    $ git commit -m "Add Rake task to build Jekyll site"
    [master 94f664b] Add Rake task to build Jekyll site
     3 files changed, 10 insertions(+)
     create mode 100644 Rakefile

    Finally, we can push the app to Heroku!

    $ git push heroku master
    warning: not sending a push certificate since the receiving end does not support --signed push
    remote: Compressing source files... done.
    remote: Building source:
    remote: -----> Ruby app detected
    remote: -----> Compiling Ruby
    remote: -----> Using Ruby version: ruby-2.4.2
    remote: -----> Installing dependencies using bundler 1.15.2
    remote:        Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
    remote: -----> Detecting rake tasks
    remote: -----> Precompiling assets
    remote:        Running: rake assets:precompile
    remote:        Configuration file: /tmp/build_c29844d07a39f5ce14fd64c34fc17680/_config.yml
    remote:        Source: /tmp/build_c29844d07a39f5ce14fd64c34fc17680
    remote:        Destination: /tmp/build_c29844d07a39f5ce14fd64c34fc17680/_site
    remote:        Incremental build: disabled. Enable with --incremental
    remote:        Generating...
    remote:        done in 0.901 seconds.
    remote:        Auto-regeneration: disabled. Use --watch to enable.
    remote:        Asset precompilation completed (1.49s)
    remote: ###### WARNING:
    remote:        No Procfile detected, using the default web server.
    remote:        We recommend explicitly declaring how to boot your server process via a Procfile.
    remote: -----> Static HTML app detected
    remote:   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
    remote: 100  838k  100  838k    0     0  5598k      0 --:--:-- --:--:-- --:--:-- 5628k
    remote: -----> Installed directory to /app/bin
    remote: -----> Discovering process types
    remote:        Procfile declares types     -> (none)
    remote:        Default types for buildpack -> web
    remote: -----> Compressing...
    remote:        Done: 26.4M
    remote: -----> Launching...
    remote:        Released v3
    remote: deployed to Heroku
    remote: Verifying deploy... done.
     * [new branch]      master -> master

    Open the URL at the end and enjoy your new Jekyll app on Heroku!

  • Announcing PCI Compliance for Heroku Shield (Heroku)
    02 Nov 2017 15:46

    In June we announced Heroku Shield with new high compliance features for Heroku Private Spaces. Heroku Shield enables businesses like AlignTech to deploy apps that handle protected healthcare information (PHI) in accordance with government regulations.

    Today, we are proud to announce that Heroku Shield Services have been validated as PCI Level 1 Service Provider compliant. This designation helps our customers understand how Heroku's systems and human processes work together to safeguard customer data. It helps security and audit teams in choosing Heroku as a platform for running a company's most critical apps.

    Further Strengthening Trust with PCI

    The Payment Card Industry Data Security Standard (PCI DSS) is one of the most widely known, industry-defined security standards. It mandates explicit security controls and requires certified organizations to be audited by a qualified security assessor. The combination of rigor and broad adoption makes PCI a valuable tool for building trust between Heroku and our customers.

    The Security + Agility Challenge

    Growing a successful business and acquiring satisfied and trusting customers is a significant feat and is something to protect carefully. It is only natural that as a business grows, it becomes more risk averse. But when risk aversion leads to resistance to change it creates another existential risk when the business is no longer adapting to the market.

    Businesses rely on Heroku to drive change. Heroku gives dev teams a way to rapidly evolve the customer experience while meeting complex compliance requirements around change control, OS system patching, access controls, encryption, intrusion detection, business continuity and more. Heroku's platform acts as an interface between continuous delivery teams and centralized security and compliance functions that makes life easier for both. For example, when an app runs in a Shield Private Space, the security team knows that all access to production is keystroke logged and that vulnerable TLS protocols are not used, etc. No ongoing audit of the tooling or infrastructure is needed because no one had to build any tools or infrastructure. Code reviews and audits are simpler because the app code has to perform fewer security functions. Because production access can be safely granted to the dev team, developers can properly monitor their production applications, quickly diagnose bugs and performance problems, and deploy fixes right away.

    Learn More

    Come meet members of our security team at our Dreamforce technical session on Heroku Shield on Wednesday November 8. For more information on Heroku Shield Services and our approach to compliance, see the Dev Center article, or contact Heroku.

  • Announcing Heroku Private Space Peering for AWS (Heroku)
    01 Nov 2017 15:34

    Two years ago, we introduced Heroku Private Spaces as a new platform abstraction that combines powerful network isolation features with the seamless developer experience of Heroku.

    Today we are announcing Heroku Private Space Peering, a new capability to connect the isolated Private Space network to apps and services in Amazon VPCs controlled by you. Now you can build apps in Heroku that connect securely and privately to backend systems and workloads in AWS like a directory service, a search stack, a data warehouse, or a legacy SQL database.

    How It Works

    Private Space Peering is available to all Heroku Enterprise customers. Setting up a peering connection takes just a few simple actions. After you have initiated the peering connection on your Amazon VPC, it will show up in the list of peerings for your Private Space in the Dashboard Network tab:

    Pasted image at 2017_10_31 10_23 PM

    Heroku will automatically route dyno network traffic destined for your VPC network via the VPC connection ensuring that it never transits the public Internet. This allows you to expose your AWS hosted applications to Heroku apps without adding an Internet gateway and routing Internet traffic into your VPC. Similarly, you can securely connect Heroku apps to AWS services like Amazon RDS and Amazon Redshift that runs in VPCs. Peering based connectivity is guaranteed to please your network security team, shorten network review audits, and open up new PaaS use cases that previously couldn't meet security requirements.

    Transforming to Cloud Native with Heroku and AWS

    By now, most IT organizations are executing projects to move existing workloads to the cloud and move to cloud native architectures like 12 Factor where possible. Heroku offers many benefits in terms of developer productivity, reduced operations complexity, and simplified governance. Some workloads are more complex and require more flexibility. Therefore, many organizations follow a pragmatic strategy of using both AWS and Heroku to transform IT. With Heroku Private Space Peering, dev teams can now build apps in Heroku that connect securely and privately to existing backend systems and workloads in AWS like a directory service, a search stack, a data warehouse, or a legacy SQL database. Never before have IT teams had this kind of power and flexibility to modernize and optimize for agility without compromising security.

    Learn More

    If you’re attending Dreamforce, make sure to catch the Private Spaces session on Tuesday, November 7 at 430pm or stop by the Heroku booth. Or, if you’re attending AWS re:Invent come check out our joint technical session with AWS. For more information see the Heroku Private Spaces and VPC Peering Dev Center articles, or contact Heroku.

  • Heroku Connect Update: Fast Writes, Global Deployment, and a Guided Management Experience (Heroku)
    26 Oct 2017 15:43

    Today we are pleased to announce a significant update to Heroku Connect, one that is a culmination of two years of work to improve every aspect of the service. We’ve focused on three primary areas: improving write speed, geographically expanding the service, and intelligently guiding design and troubleshooting workflows. To that end, we’ve enabled bulk writes resulting in a 5x average increase in sync performance to Salesforce, deployed Connect in six global regions to be closer to customers’ databases, and built three guided management experiences that significantly increase user productivity.

    Collectively, these enhancements will enable Heroku Connect to continue to meet the ever increasing demands of enterprise customers.

    Enterprise Scale Data Integration

    We’ve been fortunate to see rapid adoption of Connect amongst our largest enterprise customers. Not surprisingly, these customers tend to have large amounts of data, complex data models, and very high expectations when it comes to performance. The set of features detailed below provide substantial increases in speed and resiliency of data synchronization.

    Fast Writes

    Undoubtedly our single most requested feature, bulk writes to Salesforce is now a reality. As of today, the feature is in public beta with opt-in available via a support request. In our testing we’ve observed 4-5x performance increases over the SOAP API. If you have a need to push large batches of updates to Salesforce, this is the only way to go.

    Resilient Writes

    One of the key benefits of Heroku Connect is its built-in knowledge of Salesforce; another key benefit is resiliency. The two come together in this feature, which automatically pauses and queues pending write operations anytime that Salesforce is unavailable (i.e., maintenance windows). Once connectivity is restored, changes are automatically sent over to Salesforce. No need for manual intervention or custom coding, it just works.

    Fast Reads

    Bulk API queries previously required a second, post-processing step to fetch and subsequently write foreign keys to related tables in Postgres. Heroku Connect can now do everything in a single pass and the result is a 5x reduction in overall time to fully complete bulk load operations. The more complex the data model, the more time will be saved.

    Global Deployment

    Connect is now deployed globally to each of our six Private Space regions: Dublin, Tokyo, Sydney, Frankfurt, Virginia, and Oregon. Not only does this enable addressing data isolation requirements, it provides a large performance increase in synchronization speed by virtue of being able to co-locate Heroku Postgres and Connect with Salesforce. Moving forward, this will form the foundation of our compliance-focused initiatives.

    Intelligently Guided Configuration

    Over the years we’ve observed that a significant percentage of Connect customer issues are rooted in suboptimal design decisions. When you consider how easy it is to setup Connect (be it correctly or incorrectly), in many cases these are literally day 0 decisions coming back to haunt months later. Other times, the world changes around Connect, configurations become outdated, and errors begin to surface. Taken together, these high-level use cases represented a tremendous opportunity to improve the overall user experience across the full application lifecycle.

    Schema Change Detection

    Data models change - it’s a fact of life. Salesforce admins make changes to Salesforce objects. ORMs make changes, sometimes unexpectedly, to Postgres databases. Internally, we call this ‘schema drift’ and, as you might expect, changes to data types, lengths, and structure all have the potential to break synchronization. Heroku Connect will now detect schema changes and provide very specific reports to users, detailing precisely what changed and how. We can’t prevent change, nor would we want to, but we now make it easy to quickly and easily recover from unintended consequences.

    Connect Diagnose

    This feature provides an easy way to assess the health of your connections at runtime by way of of the new connect:diagnose command. The result is a robust set of well-documented checks against best practices and recommended design patterns delivered in a concise, easy to parse format. This is particularly useful when troubleshooting or filing support tickets. Here’s a sample of the Connect Diagnose output:


    Design Time Validations

    As the name implies, these are design-time checks, done in real-time, with the goal of making it easy to properly configure Connect. Each validation is backed by a dedicated section in our documentation that explains the issue and why you should care. Design Time Validations and Connect Diagnose work against a shared a repository of validation rules. The primary distinction between the two is when and how the validations are surfaced. Here’s an example of how we display validations in the user interface at design time:


    Learn More About Heroku Connect Today

    This update of Connect delivers a robust set of new features designed to meet the needs of enterprise customers. To learn more about Heroku Connect, checkout the Heroku Connect page and the Heroku Connect Elements listing. If you’re an existing customer and would like to participate in the bulk writes beta, let us know by visiting Heroku Help.

  • PostgreSQL 10 Now Available in Beta on Heroku Postgres (Heroku)
    17 Oct 2017 15:49

    Earlier this month, PostgreSQL 10.0 was released. Today, we are excited to announce PostgreSQL 10 is available in beta on Heroku, bringing a number of notable feature and performance improvements to our managed PostgreSQL database service.

    The beta provides customers who want to try out the new release an easy way to do so, while customers who are happy with the current version can continue to stay on version 9.6 until we make version 10 generally available. Also, new databases will continue to default to version 9.6 until we release version 10 to GA.

    While PostgreSQL 10 has many feature and performance benefits, we’d like to highlight several that we are most looking forward to:

    Performance Improvements

    Most Heroku Postgres users will notice a performance boost when using PostgreSQL 10 for certain types of queries. The introduction of improved parallel queries, which optimize common types of JOINs and table scans, will result in faster queries on many kinds of datasets.

    Additionally, the introduction of multivariate statistics objects enables users to significantly enhance query performance on any datasets which contain correlated data: STATISTICS objects can be used to let the query planner know about relationships within your data. This section of the PostgreSQL 10 manual explains the feature in more detail.

    Native Table Partitioning

    You may know we support table partitioning on previous PostgreSQL versions through the pg_partman extension which allows both time-based and serial-based table partition sets. By automatically segmenting data into seperate physical stores, Postgres table partitioning can be a great way to keep good query performance for very large tables. In PostgreSQL 10, users will have the option to leverage native table partitioning.

    PostgreSQL 10 native partitioning is possible by column but also by any arbitrary expression: in the following example we partition the users table by the first letter of a user's name.

    CREATE TABLE users (
        id             serial not null,
        name           text not null,
        created_at     timestamptz not null
    PARTITION BY RANGE ( LOWER( LEFT( name, 1 ) ) );
    CREATE TABLE users_0
        partition of users (id, primary key (id), unique (name))
        for values from ('a') to ('f');
    CREATE TABLE users_1
        partition of users (id, primary key (id), unique (name))
        for values from ('f') to ('z'); 
    INSERT INTO users (name, created_at)
        VALUES ('camille', now()),
               ('greg', now());
    SELECT * FROM users_0;
    id |  name   |          created_at           
     1 | camille | 2017-10-13 18:45:17.882299+00
    (1 row)
    SELECT * FROM users_1;
     id | name |          created_at           
      2 | greg | 2017-10-13 18:45:17.882299+00
    (1 row)

    You can find more information on PostgreSQL native partitioning and its limitations on the PostgreSQL wiki.

    Other improvements and features we are excited about include replicated hash indexes and transaction status checking.

    Getting Started and Caveats

    You can add a Postgres 10 instance via the CLI:

    heroku addons:create heroku-postgresql --version 10
    heroku pg:info DATABASE_URL
    Plan:                  Hobby-dev
    Status:                Available
    PG Version:            10.0

    At present, all Heroku Postgres extensions - except for pg_partman, plv8 and redis_fdw - are supported while PostgreSQL 10 is in beta on Heroku. pg:backups is also supported on PostgreSQL 10.

    Additionally, pg:upgrade to PostgreSQL 10 is temporarily unavailable pending extension support and testing by our team. If you want to transfer data from your existing database, you can use pg:copy for now.

    Along with version 10 in beta, we currently support PostgreSQL versions 9.3, 9.4, 9.5 and 9.6 in GA. Once we gain confidence in this release through user testing and validation, we will make PostgreSQL 10 the default for all new databases on Heroku.

    Please contact us with any feedback, bugs, or questions at

  • Container Registry & Runtime GA: Deploy Docker Images to Heroku (Heroku)
    03 Oct 2017 16:00

    In the last few years Docker has emerged as a de facto standard for packaging apps for deployment. Today, Heroku Container Registry and Runtime is generally available, allowing you to deploy your Docker images directly to Heroku.

    With Container Registry, you get all of the benefits of Docker -- a great local development experience and flexibility to create your own stack -- with the benefits of running on Heroku: maintained infrastructure, container orchestration, routing, the leading add-ons ecosystem, and a world-class security & operations team.

    To deploy your Docker image to Heroku, simply run one command in the directory of your Dockerfile:

    $ heroku container:push web
    === Building web
    Step 1 : FROM alpine:latest
    Successfully built 74bab4bf0df3
    === Pushing web
    The push refers to a repository []
    c8821d626157: Pushed

    Heroku Container Registry allows you to easily build your Docker image locally and deploy to Heroku. Both Common Runtime and Private Spaces are supported.

    To get started, check out the Container Registry documentation.

    Use Docker to Develop Your Heroku App

    It can be especially frustrating when code that runs perfectly on your machine fails to run on another developer’s machine or a test/production environment. To solve this problem, many development teams are adopting container technologies, like Docker, to fully isolate their app from the underlying OS and local environment.

    Docker is well-suited for local development, because a container that runs on your machine gives you confidence that it will also work on another developer’s machine. As a Heroku developer you can now add Docker to your toolbelt and take advantage of the local development experience it provides. When your code is ready, simply push the image directly to Heroku.

    Create Your Own Stack

    Traditionally, applications deployed on Heroku use a Ubuntu-based stack. With Container Registry you can use any base image, such as Alpine. You can also install any dependency, giving you choice in the stack that you run on Heroku.

    In this example Dockerfile, we use an Alpine image, install the Python runtime, as well as ImagicMagick from the apk package manager.

    # Grab the latest alpine image
    FROM alpine:latest
    # Install python runtime
    RUN apk --update add python3 py-pip py-gunicorn py-psycopg2 bash 
    # Install ImageMagick
    RUN apk add imagemagick
    # Install dependencies
    ADD ./python-getting-started/requirements.txt /tmp/requirements.txt
    RUN pip install -qr /tmp/requirements.txt
    # Add our code
    ADD ./python-getting-started  /opt/webapp/
    WORKDIR /opt/webapp
    # Run the app.  CMD is required to run on Heroku            
    CMD gunicorn gettingstarted.wsgi --log-file -

    How Is Container Registry Different than git push heroku master?

    When you run git push heroku master your app is built with a buildpack and runs on a Ubuntu-based stack, both of which are maintained by Heroku. We provide a curated experience ensuring the OS, binaries, language runtime, and popular dependencies are up-to-date.

    By using Docker you get the flexibility of defining your own stack, plus the benefits of running on Heroku, such as maintained infrastructure, a security and SRE team, platform orchestration of containers & routing, and a robust ecosystem of add-on services. It’s your stack to curate, backed by Heroku.

    We’re Just Getting Started

    Today, Container Registry and Runtime provides you with more choice; choice in tools you use to develop and choice in stack you use in your app. And with Container Registry and Runtime, we’re just getting started; exciting new features for customizing your build are on the horizon. If you have feedback about Container Registry, we’d love to hear from you:

  • In the Cloud, No One Can Hear Your OutOfMemoryError (Heroku)
    02 Oct 2017 15:24

    Pushing an app to the cloud can feel like launching a probe into space. Once your project is thousands of miles away you can't bang on it with a hammer or replace broken parts when there's a problem. Your debugging efforts must rely on the instrumentation, telemetry, and remote controls included with the app when it was deployed. On Heroku, we've gladly done some of that prep work for you.

    Two new Heroku features, Heroku Exec and Language Runtime Metrics, improve your production monitoring, inspecting, and debugging experience on the platform. With Heroku Exec, you can create secure TCP and SSH tunnels into a dyno, which facilitate SSH sessions, port forwarding, remote debugging, and most popular diagnostic tools. Our Language Runtime Metrics feature supplements these tools by displaying detailed time series metrics in your Heroku dashboard.

    You can try Heroku Exec right now by running the following command on any Heroku app:

    $ heroku ps:exec
    Establishing credentials... done
    Connecting to web.1 on ⬢ evening-lowlands-62983...
    ~ $

    This creates an SSH session into a running dyno, which makes it possible to inspect your application's Java process with commands like jstat and jcmd. To make this even easier, we've integrated the most popular tools, including jmap and VisualVM, directly into the Heroku CLI so you can run commands such as heroku java:jmap to get a heap dump from a dyno.

    Let's take a closer look at how you can use these features to debug real production problems by testing them on a Java application with a memory leak.

    Inspecting an App with the Heroku Java CLI

    You can follow the steps in this section with your own Java app running on Heroku, or you can use the sample app we've created, which includes a synthetic memory leak. You'll use the Heroku Java CLI to inspect the process with VisualVM and other diagnostic tools to identify the source of the leak.

    Make sure you have a Heroku account and have installed the Heroku CLI, then run the following commands to deploy the sample app:

    $ git clone
    $ cd java-memory-leak
    $ heroku create
    $ git push heroku master

    Open the app in a browser by running:

    $ heroku open

    The page will tell you exactly how much memory has been leaked, and it will grow each time you refresh. Unfortunately, most real-world leaks are not this polite, and must be uncovered with monitoring tools. The Java Development Kit (JDK) comes bundled with several of these tools, a few of which are integrated into the Heroku Java CLI. To start, install the Java CLI plugin by running this command:

    $ heroku plugins:install heroku-cli-java

    Now use the CLI to connect a local VisualVM session, a lightweight profiler for the Java virtual machine, to your remote Heroku dyno by running:

    $ heroku java:visualvm

    The command will create the connection and open VisualVM. You can see a demonstration in this video:

    Refresh your app's web page a few times. As the memory leak grows, you'll also see the process's heap memory grow in VisualVM. This helps you identify that the leak is confined to heap memory as opposed to off-heap memory. But it doesn't narrow down the objects at the source of the growth. For that, you can use the jmap command like this:

    $ heroku java:jmap --hprof
    Establishing credentials... done
    Generating heap dump for web.1 on ⬢ pure-tor-76648...
    Dumping heap to /app/heapdump-5865f5e1-956a-4f60-8d66-8571b645a950.hprof ...
    Heap dump file created
    Downloading... ████████████████████████▏ 100% 00:00

    This downloads a binary heap dump from the dyno, which can then be imported into tools like Eclipse Memory Analyzer (MAT) for analysis. Indeed, when you open the HPROF file in Eclipse MAT, its leak suspects report correctly identifies that the Servlet is holding on to some very large FakeLeak objects:

    Eclipse Mat

    Eclipse MAT, VisualVM, and jmap are great when you know you have a problem, but they are not tools you'll want to run continuously. For passive metrics monitoring, you need a low-overhead, zero-fuss solution.

    Monitoring a Production App with Heroku JVM Metrics

    The Heroku Language Runtime Metrics feature gathers detailed performance information from your application process and displays it in the Heroku Dashboard. This differs from our existing application metrics, which are gathered from the operating system and the Heroku platform. An application process's runtime can report more specific metrics, such as heap memory use and garbage collection activity, which provide better visibility into how your code is working.

    To enable this feature, you'll first need to upgrade to a paid, Standard or above, dyno. Then add the Heroku Metrics buildpack to your app by running the following commands:

    $ heroku buildpacks:add -i heroku/metrics

    Finally, make an empty commit to your application, and redeploy:

    $ git commit --allow-empty -m "Add Heroku Metrics Buildpack"
    $ git push heroku master

    Browse to the Heroku Dashboard for your application, and view the Metrics tab. Below the standard memory and dyno load charts, you'll see the JVM metrics:


    These charts display heap memory (memory used for each object your program creates), non-heap memory (which includes Metaspace and buffer pools), and garbage collection activity. The metrics are reported by a small Java agent that Heroku attaches to your application process. This agent uses Prometheus, an open-source systems monitoring and alerting toolkit. We've chosen Prometheus because it's mature, has an active community, and is independent open-source project governed by the Cloud Native Computing Foundation.

    Heroku Language Metrics support for JVM languages is generally available, and support for Go is in beta. We'll have more languages coming soon.

    Bring Your Java Apps Down to Earth

    Your app may be physically running on servers in another country or continent, but that doesn't mean you have to forgo the tooling that helps you solve problems. We're lucky to have such excellent monitoring and debugging tools in the Java ecosystem, and at Heroku we're happy to make them easily available for you.

    For more information on the Heroku Java CLI, see the Heroku Exec article in Dev Center. For more information on JVM Runtime Metrics, see the Language Runtime Metrics article in Dev Center.

  • Heroku Exec and Language Runtime Metrics GA: Runtime Debugging on Heroku (Heroku)
    28 Sep 2017 15:54

    We’ve all been there -- you push your code to production and a leak causes memory usage to grow out of control. To determine the root cause of the problem, you need to be able to monitor, inspect, and debug the production application, collecting detailed data at runtime.

    Today we’re making it even easier to debug your applications on Heroku, with the general availability of Language Runtime Metrics, starting with JVM languages, and Heroku Exec. Language metrics surfaces key indicators of an issue, like garbage collection activity, and heap and non-heap memory usage, on a unified timeline in the Heroku Dashboard.

    After you’ve identified an issue, you can use Exec to connect to a dyno at runtime, via SSH, for further inspection and remote debugging. When combined with Application Metrics, Language Runtime Metrics and Exec provide a robust set of tools for maintaining production application health.

    Runtime Inspection with Exec: SSH to the Dyno

    When a problem arises, and you need to collect data at runtime, you can connect to a dyno via SSH with Exec:

    $ heroku ps:exec
    Establishing credentials... done
    Connecting to web.1 on ⬢ ns-pipeline-staging... 
    ~ $ top

    Unlike heroku run bash, which creates a one-off dyno, Exec makes an SSH connection directly to an existing dyno (e.g., web.2). Exec also allows you to copy files off of a dyno, forward traffic on a local port to a dyno, and take advantage of common Java debugging tools.

    Connecting a Remote Debugger & Java Tools

    While top and ps are great for debugging memory issues, sometimes you need to connect a remote debugger, such as Eclipse, IntelliJ or WebStorm, and step through code. With Exec, you can forward traffic from a local port to a dyno, enabling you to connect your remote debugger.

    $ heroku ps:forward 5858

    To see an example, check out the video above.

    For Java applications, you can use JVM-specific commands to emit jmap and jstack dumps. Exec also offers the ability to connect JConsole and VisualVM to an application with one command.

    Monitoring Production Applications with Language Runtime Metrics

    Language metrics are displayed within the Application Metrics dashboard so you can easily correlate language runtime health to overall application health.


    Language runtime metrics uses the prometheus agent, which provides a lightweight method for gathering data. The additional metrics collection has minimal impact on application performance. The initial release supports JVM languages, with additional languages in progress.

    We’d Love Your Feedback

    Exec and Language Runtime Metrics are now generally available and we have plans to extend our language-specific metrics and tools support beyond Java. If you have feedback on either product, or want to share tools you would like us to support in the future, please let us know!

  • Announcing the Dublin, Ireland Region for Heroku Private Spaces (Heroku)
    26 Sep 2017 15:51

    We are excited to announce the Dublin region for Heroku Private Spaces is now generally available for Heroku Enterprise customers. Dublin joins the growing list of regions that Private Spaces supports: Sydney, Virginia, Oregon, Frankfurt, and Tokyo. With the Private Spaces Dublin region, organizations can build and deploy Heroku-style apps closer to their UK customers, reducing network latency and providing a better user experience.

    Heroku Private Spaces, available as part of Heroku Enterprise, is a network isolated group of apps and data services with a dedicated runtime environment, provisioned by Heroku in a geographic region you specify. With Spaces you can build modern apps with the powerful Heroku developer experience and get enterprise-grade secure network topologies. This enables your Heroku applications to securely connect to on-premise systems on your corporate network and other cloud services, including Salesforce.


    To create a Private Space in Dublin, select the Spaces tab in Heroku Dashboard in Heroku Enterprise, then click the “New Space” button and choose “Dublin, Ireland” from the the Space Region dropdown.

    Or you can create the space in the CLI by running:

    $ heroku spaces:create my-new-space --region dublin --team my-team
    Creating space my-new-space in team my-team... done

    After a Private Space in Dublin is created, Heroku apps can be created inside it as normal. All of Heroku’s data add-ons, Postgres, Redis, and Kafka, are also available in Dublin as are a variety of third-party Add-ons.


    All Heroku Enterprise customers can immediately begin to create Private Spaces in Dublin and deploy apps there. If there are regions which you would like us to support in the future, please let us know.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>