This is the official Heroku buildpack for Python apps, powered by Pipenv, pip and other excellent software. Recommended web frameworks include Django and Flask. The recommended webserver is Gunicorn. There are no restrictions around what software can be used (as long as it's pip-installable). Web processes must bind to $PORT, and only the HTTP protocol is permitted for incoming connections.
https://www.heroku.com/pythonTags | heroku heroku-buildpack shell python-runtime python-apps django flask |
Implementation | Shell |
License | MIT |
Platform |
Deploy React.js web apps generated with create-react-app. Automates deployment with the built-in bundler and serves it up via Nginx. See the introductory blog post and entry in Heroku elements. This buildpack deploys a React UI as a static web site. The Nginx web server provides optimum performance and security for the runtime. See Architecture for details.
buildpack heroku react spa create-react-app heroku-buildpackThis is the official Heroku buildpack for Java apps. It uses Maven 3.3.9 to build your application and OpenJDK 8 to run it. However, the JDK version can be configured as described below. The buildpack will detect your app as Java if it has a pom.xml file, or one of the other POM formats supports by the Maven Polyglot plugin, in its root directory. It will use Maven to execute the build defined by your pom.xml and download your dependencies. The .m2 folder (local maven repository) will be cached between builds for faster dependency resolution. However neither the mvn executable or the .m2 folder will be available in your slug at runtime.
The above method always uses the latest version of the buildpack. To use a specific older version of the buildpack, see notes below. This buildpack supports Heroku CI. To enable viewing test runs on Heroku, add tapex to your project.
heroku-buildpack elixirIf you want to be on the bleeding edge and use pre-release features, then use git://github.com/CHH/heroku-buildpack-php#development as buildpack url. This buildpack detects apps when the app has a composer.lock in the app's root.
NOTE: This version is DEPRECATED. Please use the heroku-16 branch. This is a Heroku buildpack for applications which use R for statistical computing and CRAN for R packages.
heroku-buildpack r shiny multiple-buildpacks herokuThis is the official Heroku buildpack for Go. This buildpack adds a heroku build constraint, to enable heroku-specific code. See the App Engine build constraints article for more info.
This is the official Heroku buildpack for Scala apps. It uses sbt 0.11.0+. The buildpack will detect your app as Scala if it has a project/build.properties file and either a .sbt or .scala based build config (for example, a build.sbt file). It vendors a version of sbt into your slug (if you are not using sbt-native-packager, it also includes your popluated .ivy/cache in the slug). The .ivy2 directory will be cached between builds to allow for faster build times.
This is the official Heroku buildpack for Node.js apps. In production, you frequently want to lock all of your dependencies - including buildpacks - to a specific version. That way, you can regularly update and test them, upgrading with confidence.
Heroku buildpack: Wordpress on Heroku
This is a Heroku buildpack for Swift apps that are powered by the Swift Package Manager.Check out the Curassow-example-helloworld for a fully working example that can be deployed to Heroku.
NOTE: This buildpack is in an experimental OSS project. This is a buildpack for handling static sites and single page web apps.
This is the official Heroku buildpack for PHP applications. It uses Composer for dependency management, supports PHP or HHVM (experimental) as runtimes, and offers a choice of Apache2 or Nginx web servers.
This is a Heroku Buildpack for Ruby, Rack, and Rails apps. It uses Bundler for dependency management. This buildpack requires 64-bit Linux.
This buildpack supports frameworks like Yesod, Snap, and Happstack with the latest stable GHC binaries. Putting Haskell web applications online should be easy, and now it is. Try it for yourself. The first deploy is slowest as the environment downloads and bootstraps. Subsequent deploys use cached binaries and cached cabal packages to go faster.
Tool to deploy Elixir & Phoenix apps to servers. To deploy to Heroku, use the Heroku Elixir buildpack instead.
This is an example Heroku buildpack. The buildpack will detect that your app has a hello.txt in the root. If this file has contents, it will be copied to goodbye.txt with instances of the world hello changed to goodbye.
This is a Heroku buildpack that allows one to run pgbouncer and stunnel in a dyno alongside application code. It is meant to be used in conjunction with other buildpacks. The primary use of this buildpack is to allow for transaction pooling of PostgreSQL database connections among multiple workers in a dyno. For example, 10 unicorn workers would be able to share a single database connection, avoiding connection limits and Out Of Memory errors on the Postgres server.
A recent change to the buildpack has made caching much more aggressive. If you are having trouble deploying run... Be sure to replace APPNAME with your app's name. Now, push your repo up. Once that build is complete, your dependencies are rebuilt and cached. Now, unset the var...
Nginx-buildpack vendors NGINX inside a dyno and connects NGINX to an app server via UNIX domain sockets. Some application servers (e.g. Ruby's Unicorn) halt progress when dealing with network I/O. Heroku's Cedar routing stack buffers only the headers of inbound requests. (The Cedar router will buffer the headers and body of a response up to 1MB) Thus, the Heroku router engages the dyno during the entire body transfer –from the client to dyno. For applications servers with blocking I/O, the latency per request will be degraded by the content transfer. By using NGINX in front of the application server, we can eliminate a great deal of transfer time from the application server. In addition to making request body transfers more efficient, all other I/O should be improved since the application server need only communicate with a UNIX socket on localhost. Basically, for webservers that are not designed for efficient, non-blocking I/O, we will benefit from having NGINX to handle all I/O operations.
We have large collection of open source products. Follow the tags from
Tag Cloud >>
Open source products are scattered around the web. Please provide information
about the open source projects you own / you use.
Add Projects.