Get the most recent info and news about Heroku on HackerNoon, where 10k+ technologists publish stories for 4M+ monthly readers.

Heroku, Inc. provides cloud computing solutions for developers. The Company offers software platform for building, deploying, and managing web applications. Heroku serves customer in the United States.

Heroku

heroku

Full operating systems that are recommended by the FSF because they are exclusively free software. Hardware that supports free software Get information about hardware support for free software. Knowing which hardware devices support GNU/Linux is important ...

Free software resources

Trading options is the process of buying and selling stocks at a pre-negotiated price by a certain date. Options are a type of contract that gives the trader the right to buy or sell a particular ...

Best Options Trading Software

This guide will cover everything from how being a software affiliate marketer works, how you stand to profit from getting involved, and how to choose the best software affiliate programs available. Software affiliate networks connect publishers with ...

Software Affiliate Programs (2022)

The cybersecurity experts at Cybernews conducted thorough hands-on tests on numerous services to uncover the best antivirus software in 2023. Besides our firsthand experiences, these selections merge insights from autonomous labs like AV-TEST, AV ...

Best antivirus software for 2023

The best video editing software gives you post-production control over your footage. With visual content constantly growing in popularity, these apps are essential for marketing a business ...

Best video editing software (2023): Video editors for Windows, Mac and more

However, there are many different types of scanning software available, and different document types available. The best scanning software will be able to cater for a range of different needs and ...

Best scanning software of 2023

Despite economic fears, Gartner predicts spending on software will increase 11% in 2023, up to $879 billion from $790 billion in 2022. Why? The answer is simple. No business can survive in today ...

Four Crucial Steps For Successful Software Implementation

When the Agile Manifesto came out in 2001, it stated that one of the 12 principles of agile software is that “the best architectures, requirements and designs emerge from self-organizing teams.”

Does Software Architecture Still Matter?

The best antivirus software can help keep your Windows computers protected against malware and other cyber threats. Although Microsoft's Windows Defender antivirus may be enough to keep your PC ...

The best antivirus software 2023: Free and paid options

The Heroku team has long been an advocate of CI/CD. Their platform integrates with many third-party solutions like GitLab CI/CD or GitHub Actions. In a previous article, I demonstrated how you can configure your Heroku app with GitLab CI/CD to automatically deploy your app to production. In a follow-up article, I walked you through a slightly more nuanced setup involving both a staging environment and a production environment. But if you want to go all in on Heroku, you can use a series of solutions called Heroku Flow to configure all your CI/CD without any third parties. Heroku Flow brings together Heroku pipelines, Heroku CI, Heroku review apps, a GitHub integration, and a release phase. In this article, I’ll show you how to set this up for your own projects. Getting Started Before we begin, if you’d like to follow along, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here, and you can create a GitHub account here. The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub. Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’ll create a Heroku pipeline that includes a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Well done! Creating Our Staging and Production Apps Most engineering organizations use at least two environments: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. Code in the staging environment is then promoted to the production environment to be released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the “Staging” section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now, let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s main branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. In the dialog that appears, make sure the main branch is targeted, and check the box to “Wait for CI to pass before deploy.” In our next step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. Enabling Heroku CI If we’re going to require CI to pass, we better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case, because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps that get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to review your changes manually. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine and run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables the automatic creation of review apps for each PR.
The second box ensures that CI must pass before the review app can be created.
The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline.
We created a staging app and a production app for that pipeline
We enabled automatic deploys for our staging app
We enabled Heroku CI to run tests for every PR
We enabled Heroku review apps to be created for every PR Now, let’s see it all in action. Create a PR in GitHub with any code change you’d like. I made a very minor UI change, updating the heading text from “Heroku Flow Demo” to “Heroku Flow Rules!” Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your “Tests” tab: After the CI pipeline passes, you’ll note another piece of info gets appended to your PR in GitHub. The review app gets deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes in it. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that the staging app was automatically deployed since new code was committed to the main branch. At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users. Click the “Promote to production” button on the staging app. This will open a dialog for you to confirm your action. Click “Promote” to confirm your changes. After promoting the code, you’ll see the production app being deployed. And with that, your changes are now in production for all of your users to enjoy. Nice work! Conclusion What a journey we’ve been through! In this short time together, we’ve configured everything we need for an enterprise-ready CI/CD solution. If you’d like to use a different CI/CD tool like GitLab CI/CD, GitHub Actions — or whatever else you may prefer — Heroku supports that as well. But if you don’t want to reach out to a third-party CI/CD provider, you can now do it all within Heroku with Heroku Flow. The Heroku team has long been an advocate of CI/CD. Their platform integrates with many third-party solutions like GitLab CI/CD or GitHub Actions. In a previous article , I demonstrated how you can configure your Heroku app with GitLab CI/CD to automatically deploy your app to production. In a follow-up article , I walked you through a slightly more nuanced setup involving both a staging environment and a production environment. previous article follow-up article But if you want to go all in on Heroku, you can use a series of solutions called Heroku Flow to configure all your CI/CD without any third parties. Heroku Flow brings together Heroku pipelines, Heroku CI, Heroku review apps, a GitHub integration, and a release phase. configure all your CI/CD In this article, I’ll show you how to set this up for your own projects. Getting Started Before we begin, if you’d like to follow along, you’ll need a Heroku account and a GitHub account. You can create a Heroku account here , and you can create a GitHub account here . create a Heroku account here create a GitHub account here The demo app shown in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Running Our App Locally You can run the app locally by forking the repo in GitHub, installing dependencies, and running the start command. In your terminal, do the following after forking the repo: $ cd heroku-flow-demo
$ npm install
$ npm start $ cd heroku-flow-demo
$ npm install
$ npm start After starting the app, visit http://localhost:5001/ in your browser, and you’ll see the app running locally: http://localhost:5001/ Creating Our Heroku Pipeline Now that we have the app running locally let’s get it deployed to Heroku so that it can be accessed anywhere, not just on your machine. We’ll create a Heroku pipeline that includes a staging app and a production app. To create a new Heroku pipeline, navigate to your Heroku dashboard, click the “New” button in the top-right corner of the screen, and then choose “Create new pipeline” from the menu. In the dialog that appears, give your pipeline a name, choose an owner (yourself), and connect your GitHub repo. If this is your first time connecting your GitHub account to Heroku, a second popup will appear in which you can confirm giving Heroku access to GitHub. After connecting to GitHub, click “Create pipeline” to finish the process. With that, you’ve created a Heroku pipeline. Well done! Creating Our Staging and Production Apps Most engineering organizations use at least two environments: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. Code in the staging environment is then promoted to the production environment to be released to actual users. Let’s add a staging app and a production app to our pipeline. Both of these apps will be based on the same GitHub repo. To add a staging app, click the “Add app” button in the “Staging” section. Next, click “Create new app” to open a side panel. In the side panel, give your app a name, choose an owner (yourself), and choose a region (I left mine in the United States). Then click “Create app” to confirm your changes. Congrats, you’ve just created a staging app! Now, let’s do the same thing, but this time for our production app. When you’re done configuring your production app, you should see both apps in your pipeline: Configuring Automatic Deploys We want our app to be deployed to our staging environment any time we commit to our repo’s main branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. main In the dialog that appears, make sure the main branch is targeted, and check the box to “Wait for CI to pass before deploy.” In our next step, we’ll configure Heroku CI so that we can run tests in a CI pipeline. We don’t want to deploy our app to our staging environment unless CI is passing. main Enabling Heroku CI If we’re going to require CI to pass, we better have something configured for CI! Navigate to the “Tests” tab and then click the “Enable Heroku CI” button. Our demo app is built with Node and runs unit tests with Jest. The tests are run through the npm test script. Heroku CI allows you to configure more complicated CI setups using an app.json file, but in our case, because the test setup is fairly basic, Heroku CI can figure out which command to run without any additional configuration on our part. Pretty neat! npm test app.json Enabling Review Apps For the last part of our pipeline setup, let’s enable review apps. Review apps are temporary apps that get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to review your changes manually. With a review app in place, the reviewer can simply open the review app rather than having to pull down the code onto their machine and run the app locally. To enable review apps, click the “Enable Review Apps” button on the pipeline page. In the dialog that appears, check all three boxes. The first box enables the automatic creation of review apps for each PR. The second box ensures that CI must pass before the review app can be created. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. The first box enables the automatic creation of review apps for each PR. The second box ensures that CI must pass before the review app can be created. The third box sets a time limit on how long a stale review app should exist until it is destroyed. Review apps use Heroku resources just like your regular apps, so you don’t want these temporary apps sitting around unused and costing you or your company more money. When you’re done with your configuration, click “Enable Review Apps” to finalize your changes. Seeing It All in Action Alright, you made it! Let’s review what we’ve done so far. We created a Heroku pipeline. We created a staging app and a production app for that pipeline We enabled automatic deploys for our staging app We enabled Heroku CI to run tests for every PR We enabled Heroku review apps to be created for every PR We created a Heroku pipeline. We created a staging app and a production app for that pipeline We enabled automatic deploys for our staging app We enabled Heroku CI to run tests for every PR We enabled Heroku review apps to be created for every PR Now, let’s see it all in action. Create a PR in GitHub with any code change you’d like. I made a very minor UI change, updating the heading text from “Heroku Flow Demo” to “Heroku Flow Rules!” Right after the PR is created, you’ll note that a new “check” gets created in GitHub for the Heroku CI pipeline. You can view the test output back in Heroku on your “Tests” tab: After the CI pipeline passes, you’ll note another piece of info gets appended to your PR in GitHub. The review app gets deployed, and GitHub shows a link to the review app. Click the “View deployment” button, and you’ll see a temporary Heroku app with your code changes in it. You can also find a link to the review app in your Heroku pipeline: Let’s assume that you’ve gotten a code review and that everything looks good. It’s time to merge your PR. After you’ve merged your PR, look back at the Heroku pipeline. You’ll see that the staging app was automatically deployed since new code was committed to the main branch. main At this point in the software development lifecycle, there might be some final QA or acceptance testing of the app in the staging environment. Let’s assume that everything still looks good and that you’re ready to release this change to your users. Click the “Promote to production” button on the staging app. This will open a dialog for you to confirm your action. Click “Promote” to confirm your changes. After promoting the code, you’ll see the production app being deployed. And with that, your changes are now in production for all of your users to enjoy. Nice work! Conclusion What a journey we’ve been through! In this short time together, we’ve configured everything we need for an enterprise-ready CI/CD solution. If you’d like to use a different CI/CD tool like GitLab CI/CD, GitHub Actions — or whatever else you may prefer — Heroku supports that as well. But if you don’t want to reach out to a third-party CI/CD provider, you can now do it all within Heroku with Heroku Flow. do it all

How I Got My CI/CD Act together With Heroku Flow

How To Cache RESTful API Requests for Redis With Heroku Data

Location, Location, Location! PostGIS and Heroku Postgres

অবস্থান, অবস্থান, অবস্থান! পোস্টজিআইএস এবং হেরোকু পোস্টগ্রেস

Lage, Lage, Lage! PostGIS und Heroku Postgres

¡Ubicación, ubicación, ubicación! PostGIS y Heroku Postgres

Emplacement, emplacement, emplacement ! PostGIS et Heroku Postgres

स्थान, स्थान, स्थान! PostGIS और Heroku Postgres

場所、場所、場所！PostGIS と Heroku Postgres

위치, 위치, 위치! PostGIS와 Heroku Postgres

Localização, localização, localização! PostGIS e Heroku Postgres

Местоположение, Расположение, Местоположение! PostGIS и Heroku Postgres

Konum, Konum, Konum! PostGIS ve Heroku Postgres

Vị trí, vị trí, vị trí! PostGIS và Heroku Postgres

位置，位置，位置！PostGIS 和 Heroku Postgres

In a , we explored how to automate deployments to Heroku using GitLab CI/CD. That setup deployed the app to its production environment every time we pushed code to the branch. previous article main In this article, we’ll consider a slightly more nuanced approach: What if we have multiple environments? Most engineering organizations use at least three environments: a local development environment, a staging environment, and a production environment. Additionally, some engineering teams follow a , where they have a branch and a branch. This strategy has since fallen out of favor and been replaced by , but it’s not uncommon to find organizations still following this practice. Gitflow branching strategy dev main trunk-based development Today, we will look at how to configure GitLab CI/CD to deploy our app to our staging environment when we push to the branch and deploy our app to our production environment when we push it to the branch. dev main Getting Started Before we begin, we’ll need two things: a Heroku account and a GitLab account. Heroku is a great place to host and deploy your apps. As a platform as a service (PaaS), Heroku allows you to focus on building cool things while abstracting away much of the infrastructure complexity. You can . create a Heroku account here GitLab is a great place to store your code. Beyond just being a source code management tool, GitLab also offers native CI/CD capabilities so you can set up pipelines to test and deploy your code without requiring another third-party tool. You can . create a GitLab account here The demo app shown in this article uses both GitLab and Heroku. You can . find all the code in the GitLab repo here Running Our App Locally You can run the app locally by cloning the repo, installing dependencies, and running the start command. In your terminal, do the following: $ git clone https://gitlab.com/tylerhawkins1/heroku-gitflow-staging-production-gitlab-cicd-demo.git
$ cd heroku-gitflow-staging-production-gitlab-cicd-demo
$ npm install
$ npm start After starting the app, visit in your browser, and you’ll see the app running locally: http://localhost:5001/ Deploying Our App to Heroku Now that the app is running locally let’s deploy it to Heroku so that you can access it anywhere, not just on your machine. Remember that we are going to deploy your app to both a staging environment and a production environment. That means that we’ll have two Heroku apps based on the same GitLab repo. If you don’t already have the installed on your machine, you’ll need to install it before moving on. Heroku CLI After installing the Heroku CLI, run the following commands from your terminal to check out the branch, create a new production Heroku app, deploy it to your production environment, and open it in your browser: main $ git checkout main
$ heroku create heroku-gitlab-ci-cd-production --remote heroku-production
$ git push heroku-production main
$ heroku open --remote heroku-production With that, you should see the same app, but this time running on a Heroku URL instead of on localhost. Nice work — you’ve deployed your Heroku app to production! But we’re not done yet. We also need to configure and deploy your staging app. To do this, run this similar set of commands shown below: $ git checkout dev
$ heroku create heroku-gitlab-ci-cd-staging --remote heroku-staging
$ git push heroku-staging main
$ heroku open --remote heroku-staging Now, you’ll have the same app deployed again, but this time to a different URL that will serve as your staging environment. Now we have both of your environments configured! Note the differences and similarities between the commands for the production app and the staging app: The production app uses the branch and the staging app uses the branch. main dev The production app is called , and the staging app is called . heroku-gitlab-ci-cd-production heroku-gitlab-ci-cd-staging The production app’s git remote is called , and the staging app’s git remote is called . heroku-production heroku-staging Both the production app and the staging app’s git remotes use a branch since . main Heroku only deploys the app when code is pushed to its main branch Keep in mind that branch is different from set of and branches. The branch that you’re pushing to here is the branch on your git remote — in this case, Heroku. this main your main dev main main So when you’re on your local branch and run , you’re pushing your branch to the Heroku production app’s branch. And when you’re on your local branch and run , you’re pushing your branch to the Heroku staging app’s branch. main git push heroku-production main main main dev git push heroku-staging main dev main Making Changes to Our App Now that we have our Heroku app up and running, what if we want to make some changes? Following a rough approximation of the Gitflow branching strategy, we could do the following: Check out the branch dev Make changes to the code Add, commit, and push those changes to the branch dev Deploy those changes to the staging Heroku app by running git push heroku-staging main Check out the branch main Merge the branch into the branch dev main Deploy those changes to the production Heroku app by running git push heroku-production main (If we were truly following Gitflow, we’d have created a feature branch to merge into , and a release branch to merge into , but we’ve omitted those steps to keep things simple.) dev main Now, wouldn’t it be nice if we could automate the deployment to either of our environments instead of having to deploy them manually all the time? This is where GitLab CI/CD comes into play. Continuous Integration / Continuous Deployment Continuous integration (CI) is all about committing often and keeping the build in a good state at all times. Typically you would verify that the build is in a good state by running checks in a CI pipeline. These checks might include linters, unit tests, and/or end-to-end tests. Continuous deployment (CD) is all about deploying frequently. If the checks in the CI pipeline pass, then the build gets deployed. If the checks in the CI pipeline fail, then the build does not get deployed. With GitLab CI/CD, we can configure our CI pipeline to do exactly this — run our tests and then deploy our app to Heroku if the tests all pass. Most importantly, for our setup, we can configure rules within our CI pipeline to specify where the app should be deployed. Configuring GitLab CI/CD We can create a CI pipeline in GitLab programmatically using a file. Our file looks like this: .gitlab-ci.yml image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  variables:
    HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_PRODUCTION
    - if: $CI_COMMIT_REF_NAME =~ /dev/
      variables:
        HEROKU_APP_NAME: $HEROKU_APP_NAME_STAGING
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl --provider=heroku --app=$HEROKU_APP_NAME --api-key=$HEROKU_API_KEY GitLab CI pipelines consist of stages and jobs. Each stage can contain one or more jobs. In our pipeline, we have two stages: and . In the stage, we run our unit tests in the . In the stage, we deploy our app to Heroku in the . test deploy test unit-test-job deploy deploy-job We can only progress to the next stage if all the jobs in the previous stage pass. That means if the unit tests fail, then the app won’t be deployed, which is a good thing! We wouldn’t want to deploy our app if it was in a bad state. You’ll note that the stage has a section with some conditional logic in place. This is where we specify to which environment our app should be deployed. If we’re on the branch, then we deploy our production app. If we’re on the branch, then we deploy our staging app. deploy rules main dev You’ll also note that the stage references several variables called , , and . These are stored as . deploy $HEROKU_APP_NAME_PRODUCTION $HEROKU_APP_NAME_STAGING $HEROKU_API_KEY CI/CD variables within GitLab If you’re setting this up in your own GitLab account, you’ll need to first find your API key in your Heroku account. Within your Heroku account settings, you should see a section for your API key. If you haven’t generated an API key yet, generate one now. Next, in your GitLab project, click on > > . Expand that section and add three new variables: Settings CI/CD Variables The value for will be the API key from your Heroku account. $HEROKU_API_KEY The value for will be the name of your production Heroku app. My production app’s name is , but since Heroku app names are universally unique, yours will be something different. $HEROKU_APP_NAME_PRODUCTION heroku-gitlab-ci-cd-production The value for will be the name of your staging Heroku app. My staging app’s name is . Again, since Heroku app names are universally unique, yours will be something different. $HEROKU_APP_NAME_STAGING heroku-gitlab-ci-cd-staging With that, your GitLab CI pipeline is ready to go! Let’s test it out. Deploying Our Heroku App to the Staging Environment Let’s check out the branch and make a change to the code in our app. I made a simple change to the heading text and added several new lines to the text in the UI. You can make a similar change in your code. dev Now, add, commit, and push that change to the branch. This will start the GitLab CI pipeline. You can view the pipeline within GitLab and see the progress in real-time. dev If everything goes well, you should see that both the and stages have passed. Now, go check out your hosted Heroku app at the staging environment URL. The GitLab CI pipeline took care of deploying the app for you, so you’ll now see your changes live in the staging environment! test deploy With a staging environment set up, you now have a great place to manually test your code in a hosted environment. This is also a perfect spot for QA testers or product managers to verify changes before they go to production. Now, check out your production app URL. You’ll note that it’s still showing the old UI without the most recent changes. This is because the GitLab CI pipeline only deployed the changes to the staging environment, not the production environment. We’ve verified that the code looks good in our staging environment, so let’s promote it to our production environment. Deploying Our Heroku App to the Production Environment Let’s check out the branch and then merge the branch into your branch. You could do this through a pull request or by running and then . main dev main git merge dev git push This will start the GitLab CI pipeline once again, but this time, it will be preparing to deploy your production app. You can also view all the pipeline runs on the Pipelines page in GitLab to see the various builds for your and branches: dev main Once the pipeline finishes, visit the URL for your production Heroku app. You should now see your changes also deployed in production. Great work! Conclusion A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process. Having multiple environments configured for local development, staging, and production gives you more control over where and when code is released. Heroku and GitLab CI/CD allow you to automate all of this to make your DevOps processes a breeze! Also published . here

Configuring GitLab CI/CD for Multi-Environment Deployments to Heroku

Go (aka Golang) came to life at Google in 2009. It was designed by a few big names: , who had a large hand in the development of the Java Virtual Machine. Robert Griesemer , who holds a U.S. patent for windowing UI systems, helped build the Plan 9 operating system at Bell Labs. (In fact, the mascots and are remarkably similar because Pike’s wife, Renée French, is a renowned illustrator.) Rob Pike for Plan 9 for Golang , who designed and implemented a little thing called Unix. Ken Thompson In this article, we’ll demonstrate how simple it is to build a RESTful web service in Go. Then, we’ll demonstrate how to deploy this application with Heroku. But before we embark on this journey, let’s talk briefly about you might want to use Go. why Why Go? To build a web service in 2024, why would you choose to Go over another language, like Python or TypeScript? Go’s biggest advantage over those two languages is . Go is a compiled-to-machine-code language. It’s not interpreted like Python, Ruby, or JavaScript. It’s not even compiled into bytecode and run on a virtual machine like Java. Lots of benchmarks show Go to be 40x or 50x faster than applications written in interpreted languages. When it comes to speed, Go applications perform similarly to those written in Rust or C++. speed Go has a , often with only one particular way of doing something. This is appealing to many developers, especially any who have ever been in a development team setting, where squabbles over various ways of doing things eat up precious time. This simplicity drives conformity in a codebase and offers less perplexity when the code. (Believe it or not, most developers spend more of their time code rather than writing it.) simple syntax reading reading Go is a young language, so it comes packed with modern features out of the nursery. You get automatic garbage collection like in Java or Python. You get . You get a . And perhaps most beneficial to network programmers: You get an called . built-in linters, formatters, and unit testing rich network stack in the standard library easy-to-use multi-threading toolkit Goroutines Yes, there are some reasons why not everyone is hot on Go. One common complaint revolves around error handling in Go. Functions in Go can return multiple values, one of which is an error code. This hearkens back to the days of C—before exceptions—and feels admittedly archaic. It is easy to forget to check error codes for every function. It’s also tedious to percolate errors from down in the depths—when you awaken a balrog deep inside your application—up to somewhere manageable. You know you’ve done that. Alright, the Go cheerleading is done. Let’s get to building. Building a simple RESTful web service in Go We’ll build a small API service that provides some text operations that applications commonly need, such as: Encode a given string using a basic Caesar Cipher Determine if a string is a palindrome (Perhaps most importantly) SpongeBob-encode a zinging retort. If you’d rather skip ahead to the finished code for this application, you can find it in this . We’re not going to go through line by line, but we’ll talk about the important bits. GitHub repo main.go Let’s start with the main function, the bootstrapping code of the service: func main() {
	http.HandleFunc("/is-palindrome", palindromeHandler)
	http.HandleFunc("/rot13", rot13Handler)
	http.HandleFunc("/spongebob", spongebobHandler)
	http.HandleFunc("/health", healthHandler)

	appPort := ":" + os.Getenv("PORT")
	if appPort == ":" {
		appPort = ":8080"
	}
	err := http.ListenAndServe(appPort, nil)
	if err != nil {
		return
	}
} As we mentioned, one of Go’s powerful features is the expressive standard library. You don’t need any third-party dependencies to quickly get a basic RESTful service up and running. With , you can easily define your routes and assign handlers to the requests that are routed to those URIs. net/http http.HandleFunc The method kicks off the server, binding it to the port you specify. When we deploy to Heroku, . For our local deployment, we default to . http.ListenAndServe Heroku will handle setting the PORT var in the environment 8080 Let’s look at a handler: func spongebobHandler(w http.ResponseWriter, r *http.Request) {
	decoder := json.NewDecoder(r.Body)
	var t requestPayload
	err := decoder.Decode(&t)
	if err != nil {
		panic(err)
	}

	result := map[string]string{
		"original":  *t.Input,
		"spongebob": spongebob(*t.Input),
	}

	w.Header().Set("Content-Type", "application/json")
	err = json.NewEncoder(w).Encode(result)
	if err != nil {
		return
	}
} Our handler needs to do the work of taking the JSON body of the request and parsing it into a Go struct defined outside of this snippet. Then, it needs to build the result from other functions that transform the input string into a SpongeBob utterance. Again, none of the libraries here are third-party dependencies; they all come standard with Go. You can see the prevalence of error handling here via error codes, as working with takes up a large part of the code real estate. err $ go run main.go Then, we send a GET request to : /health $ curl -s http://localhost:8080/health We receive a JSON response indicating the service is up and healthy. That’s it—one file with roughly 100 lines of actual code, and you have a working Go RESTful microservice! Deploying your Go service to Heroku Running the service on your laptop is OK, I guess. But you know what would be really cool? Running it on the web, that’s what. These days, we have lots of options for how to host a service like this. You could build out your own infrastructure using AWS or Azure, but that quickly gets complicated and expensive. Lately, I’ve been turning more and more to . As a platform-as-a-service (PaaS), it’s a low-hassle, low-cost option that allows me to deploy applications to the cloud quickly. Heroku When I’m doing testing and development, I use their Eco Dyno plan to get 1000 dyno hours per month for $5. To deploy basic apps to production, I use their Basic Dyno Plan, which costs a max of $7 per month. For frameworks that Heroku supports, the process of deploying right from your local machine to the web is quick and painless. After setting up a Heroku account, I installed the and logged in from the command line. Heroku CLI You can create a new app directly through the CLI, or you can use the web UI. I named my application the same as my GitHub repo: . We’ll think of something snazzier before our IPO, but for now, this will do. golang-text-demo To deploy our GitHub repo to Heroku, we first need to add a remote repository. $ heroku git:remote -a golang-text-demo This creates a new remote location in our GitHub repo, pointing it to the Heroku application we just created. Now, whenever we push our branch to that remote ( ), it will kick off a flurry of activity as Heroku gets to work. git push heroku main Lastly, we add one file called , which specifies our app’s build dependencies (we don’t have any) and build configurations for Heroku. Our file is short and sweet; simply setting the Go version we want Heroku to use: go.mod module golang-text-demo

go 1.22 When we push to our Heroku remote, Heroku initializes all the required resources in the cloud. This may take a minute or two the first time you deploy your app, but the results appear to be cached, reducing the time in subsequent deploys. When your app has successfully deployed, you’ll see output that looks similar to this: This gives us the URL for our deployed Heroku app. Sweet! With a single command, we’ve deployed a Go microservice to the cloud, and it is now accessible anywhere in the world. To interact with it, we simply issue the same curl command we did before, but we use the Heroku app URL instead of . git push localhost The Heroku CLI also gives us access to our application’s logs. It’s almost exactly like working with the tools directly on your local machine. We just run , and we see the latest log lines from Heroku and our application right there in our terminal window. heroku logs -tail Before we finish, let’s briefly highlight the impressive insights that can be gained about your application from the Heroku app dashboard. Sure, there’s the obvious stuff you care about—like how much your resources are costing or whether or not they are functioning. But the metrics section gives you impressive details about the performance of your application in near real time. Somebody better do something about those critical errors… 🥴 Conclusion In this walkthrough, we’ve explored why Go is a great choice for building a modern, low-dependency, and efficient web service. We built a simple API service in Go and demonstrated how to deploy our service using Heroku. As a PaaS, Heroku supports running a wide variety of services, not just Go. With that, you now have the tools needed to get started on your own Go services journey. Don’t wait, get Go-ing! Also published . here

How I Built My First Go App and The Deployed it to Heroku

How to secure your apps with SSL certificates for custom domains If you’re building an application that needs to go toward production, you’ll undoubtedly need to serve it up securely with SSL. What that entails varies from provider to provider, and you’ll encounter differing levels of complexity (and cost) in getting it all setup. Fortunately, if you’re using Heroku to run your application, this is pretty straightforward. Recently, I've been exploring Heroku again, and in this article, I'll delve into what you'll require to enable SSL on the platform and explore the reasons behind choosing certain features over others. What does Heroku provide for SSL right out of the box? Heroku focuses on ease of use, and I love that. Whether it’s the one-click deploy straight from my GitHub repo or the plugin ecosystem that lets me drop all kinds of great things into my app from the command line, I always appreciate the out-of-the-box options I have at my fingertips. Likewise, SSL on Heroku provides some great default options. Heroku offers two main ways of working with SSL certificates on their platform: Automated Certificate Management (ACM) Heroku SSL For most apps, ACM will give you a really simple, automated certificate management experience—that is the name, after all. But there may be times when you’ll need the more robust Heroku SSL option. We’ll take a look at ACM first. Then, we’ll investigate why you might need Heroku SSL and how you’d use it. Automated Certificate Management and how it works ACM is built on top of —a free, automated certificate authority, run by a nonprofit organization committed to enhancing the security of the web in general. While organizations can sponsor the Let’s Encrypt project, there is no cost for using Let’s Encrypt-issued SSL certificates. Because the certificates are free, Heroku provides Automated Certificate Management with any of their basic plans at no additional charge. Let’s Encrypt While Let’s Encrypt automates the process of requesting and issuing certificates, ACM automates the process of installing those certificates on the relevant apps for the domains they’re issued for. Other methods exist for automated management of certificates, but they’re paid add-ons, so I won’t be looking at them here. Instead, let’s show you how to add ACM to a demo app I’ve already deployed to Heroku. To be clear, there isn’t a whole lot you need to configure for ACM. In fact, if you haven’t added a custom domain to your app, the Heroku-generated URL (on the herokuapp.com domain) for your app already has SSL. Step 1: Enable ACM Your first step is to turn on ACM. The easiest way to do this for any deployed app is with . Assuming you’re logged into the Heroku CLI Heroku via the CLI, all you need to do is run a single command to turn on ACM: $ heroku certs:auto:enable
Enabling Automatic Certificate Management... starting.
See status with heroku certs:auto or wait until active with
heroku certs:auto --wait=== Your certificate will now be managed by Heroku.
Check the status by running heroku certs:auto. If you enable ACM setting up a custom domain on your app, you’ll get a message like this: before $ heroku certs:auto
=== Automatic Certificate Management is enabled on pure-brushlands-82324
=== Add a custom domain to your app by running: heroku domains:add <yourdomain.com> Step 2: Add a custom domain At this point, you simply need to do what the Heroku CLI says and add a domain to your app. You can do this in the CLI too. $ heroku domains:add really-cool-stuff.app
Configure your app's DNS provider to point to the DNS Target lively-basin-0v9xkh99iaz1yc0xldmakla5.herokudns.com.
    For help, see https://devcenter.heroku.com/articles/custom-domains

The domain really-cool-stuff.app has been enqueued for addition
Run heroku domains:wait 'really-cool-stuff.app' to wait for completion
Adding really-cool-stuff.app to ⬢ pure-brushlands-82324... done Step 3: Configure DNS At this point, you need to update your DNS records on your domain to point to the DNS target provided by Heroku. The are detailed and clear. Typically, this means adding a CNAME record that directs to the new location provided by Heroku. instructions in the help documentation it links to Once you have your DNS configured properly, you can check on the status of your certificates. You should see output like this: $ heroku certs:auto
=== Automatic Certificate Management is enabled on pure-brushlands-82324

Certificate details:
Common Name(s): really-cool-stuff.app
Domain(s):      fe6ab605-91f9-4261-974c-ee85c043dbf7
Expires At:     2024-05-27 17:08 UTC
Issuer:         /CN=R3/O=Let's Encrypt/C=US
Starts At:      2024-02-27 17:09 UTC
Subject:        /CN=really-cool-stuff.app
SSL certificate is verified by a root authority.

Domain                       Status       Last Updated
───────────────────────────  ───────────  ────────────
really-cool-stuff.app        Cert issued  4 minutes If you’re like me and you made a mistake when setting up the DNS records 🤦🏻, then you might see some warnings on the app dashboard in the web interface like this: Or this one: Fortunately, ACM repeats its validation attempts regularly for an entire hour. So, I was able to fix my issues quickly. I got to a green status pretty easily. If you’ve ever had to set up SSL on another platform before, you’re probably painfully aware that it usually isn’t this simple (and that’s putting it mildly). That said, Let’s Encrypt has some limitations that may require you to use the more robust offering: Heroku SSL. Heroku SSL and why you might want it While ACM gives you a really simple experience, with that simplicity also comes somewhat limited functionality. Let’s consider two examples where ACM might not meet your unique needs. Example 1: When you need wildcard certificates Let’s Encrypt is restricted to providing certificates on only one single domain name zone at a time. Sometimes, you might actually want to have a wildcard certificate; this is the type of functionality you might need if you have a multi-tenant application that switches between tenants at the subdomain level. ACM doesn’t support this. But Heroku SSL does. common name Example 2: When you need Organizational or Extended Validation (OV/EV) Let’s Encrypt also doesn’t guarantee that you are who you say you are. What I mean is that the type of certificate issued by Let’s Encrypt only attests that the entity requesting the certificate also controls the domain name that it’s securing. There are some scenarios when you need to ensure more than just that your domain traffic is encrypted in transit. You might need to verify that your application is actually associated with your company. In this case, you’d want to purchase an SSL certificate with either Organizational Validation (OV) or Extended Validation (EV). Those usually require checks that can’t be simply automated by a product like Let’s Encrypt. really Using Heroku SSL In the above cases, you’ll need to manually upload your own certificate. As usual, this process has been beautifully simplified by Heroku (but it’s still more work than just telling the platform to start issuing certificates with ACM). To add or update the certificate for your Heroku app, and to use a certificate provide, you need to run a single command: you $ heroku certs:add server.crt server.key
Adding SSL to example... done
exampleapp now served by exemplary-sushi-4gr7rb6h8djkvo9j5zf16mfp.herokudns.com.
Certificate details:
Expires At: 2022-08-18 21:53:18 GMT
Issuer: C=US; ST=CA; L=SF; O=Heroku; CN=www.example.com
Starts At: 2021-08-18 21:53:18 GMT
... Ok, so it’s not much more work than using ACM. that Note that you can’t add multiple intermediate certificates to make a valid chain toward whatever root certificate has signed your new certificate. However, you can into one file so they can be uploaded as a single file. merge your intermediate certificates After uploading your certificate through Heroku SSL, you’ll be able to see your application protected by the SSL certificate you provided on your own. While Heroku SSL still keeps things pretty simple, keep in mind that You’ll also need knowledge of how to work with certificates. While these might not be deal-breakers for you, they’re important points to remember—especially when you consider that ACM takes care of automatic renewals of SSL certificates. With ACM, the simple commands to set it up really are “set it and forget it.” That said, Heroku designed their entire certificate management system in such a way that even if you need the most advanced options, it’s still quite simple and manageable, even if you don’t have extensive certificate experience. you’re responsible for keeping your certificates up to date . Conclusion While there is more you can do with SSL on Heroku, both the ACM and Heroku SSL options can provide the functionality to fit most use cases. Heroku’s also provides enough detail to point you in the right direction. If you haven’t secured your app with SSL (shame on you!), then the simplicity of ACM should remove any excuse you have to secure your site properly. If your use case is more complicated, then Heroku SSL should give you what you need. documentation in this space

How to Secure your Heroku Apps with SSL Certificates for Custom Domains

Good teams commit and deploy frequently; in line with some of the main ideas behind . Gone are the days of quarterly or yearly releases and long-live feature branches! software engineering continuous integration (CI) and continuous deployment (CD) Today, I’ll show you how to  automatically deploy your Heroku app whenever code is merged into your main branch by using GitLab CI/CD. Ready to dig in? Getting Started Before we begin, we’ll need a and a Heroku account GitLab account. is a great place to host and deploy your apps. As a platform as a service (PaaS), Heroku allows you to focus on building cool things while abstracting away much of the infrastructure complexity. You can . Heroku create a Heroku account here is a great place to store your code. Beyond just being a source code management tool, GitLab also offers native CI/CD capabilities so you can set up pipelines to test and deploy your code without requiring another third-party tool. You can . GitLab create a GitLab account here The demo app shown in this article uses both GitLab and Heroku. You can . find all the code in the GitLab repo here Running Our App Locally You can run the app locally by cloning the repo, installing dependencies, and running the start command. In your terminal, do the following: $ git clone https://gitlab.com/tylerhawkins1/heroku-gitlab-ci-cd-demo.git
$ cd heroku-gitlab-ci-cd-demo
$ npm install
$ npm start After starting the app, visit in your browser, and you’ll see the app running locally: http://localhost:5001/ Deploying Our App to Heroku Now that the app is running locally, let’s deploy it to Heroku so that you can access it anywhere, not just on your machine. If you don’t already have the installed on your machine, you’ll need to install that before moving on. Heroku CLI After installing the Heroku CLI, run the following commands from your terminal to create a new Heroku app, deploy it, and open it in your browser: $ heroku create
$ git push heroku main
$ heroku open With that, you should see the same app, but this time running on a Heroku URL instead of on localhost. Nice work — you’ve deployed your Heroku app! Making Changes to Our App Now that we have our Heroku app up and running, what if we want to make changes? You can make changes to the source code and then add, commit, and push those changes to the branch. main If you wanted to deploy those changes to the production Heroku app, you’d need to run once again. Wouldn’t it be nice if we could automate the deployment instead of having to deploy it manually each time? git push heroku main This is where GitLab CI/CD comes into play. Continuous Integration / Continuous Deployment Continuous integration (CI) is all about committing often and keeping the build in a good state at all times. Typically you would verify that the build is in a good state by running checks in a CI pipeline. These checks might include linters, unit tests, and/or end-to-end tests. Continuous deployment (CD) is all about deploying frequently. If the checks in the CI pipeline pass, then the build gets deployed. If the checks in the CI pipeline fail, then the build does not get deployed. With GitLab CI/CD, we can configure our CI pipeline to do exactly this — run our tests and then deploy our app to Heroku if the tests all pass. Configuring GitLab CI/CD We can create a CI pipeline in GitLab programmatically using a file. Our file looks like this: .gitlab-ci.yml image: node:20.10.0

cache:
  paths:
    - node_modules/

before_script:
  - node -v
  - npm install

stages:
  - test
  - deploy

unit-test-job:
  stage: test
  script:
    - npm test

deploy-job:
  stage: deploy
  environment: production
  script:
    - apt-get update -yq
    - apt-get install -y ruby-dev
    - gem install dpl
    - dpl - provider=heroku - app=$HEROKU_APP_NAME - api-key=$HEROKU_PRODUCTION_KEY
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH GitLab CI pipelines consist of stages and jobs. Each stage can contain one or more jobs. In our pipeline, we have two stages: and . In the stage, we run our unit tests in the . In the stage, we deploy our app to Heroku in the . test deploy test unit-test-job deploy deploy-job If all the jobs in the previous stage pass, then we can progress to the next stage. That means if the unit tests fail, then the app won’t be deployed, which is a good thing! We wouldn’t want to deploy our app if it was in a bad state. You’ll notice that the stage references two variables called and . These are stored as . deploy $HEROKU_APP_NAME $HEROKU_PRODUCTION_KEY CI/CD variables within GitLab If you’re setting this up in your own GitLab account, you’ll first need to find your API key in your Heroku account. Within your Heroku account settings, you should see a section with your API key. If you haven’t generated an API key yet, generate one now. Next, in your GitLab project, click on > > . Expand that section and add two new variables. Settings CI/CD Variables The value for will be the API key from your Heroku account. $HEROKU_PRODUCTION_KEY The value for will be the name of your Heroku app. $HEROKU_APP_NAME My app’s name is , but since Heroku app names are universally unique, yours will be something different. heroku-gitlab-ci-cd-demo With that, your GitLab CI pipeline is ready to go! Let’s test it out. Deploying Our Heroku App Automatically Let’s make a change to the code in our app. I made a simple change to the heading text, changing the words from “Heroku and GitLab CI/CD Demo” to “Heroku and GitLab CI/CD Rules!” You can make a similar change in your code. Now add, commit, and push that change to the branch. This will start the GitLab CI pipeline. You can view the pipeline within GitLab and see the progress in real time. main If everything goes well, you should see that both the and stages have passed. Now, go check out your hosted Heroku app. The GitLab CI pipeline deployed the app for you, so you’ll now see your changes live in production! test deploy Now whenever you need to make and deploy changes to your app, simply commit your changes and GitLab CI/CD will take care of the rest. Conclusion A good CI pipeline allows you to ship new features quickly and confidently without manually managing the deployment process yourself. Heroku and GitLab CI/CD make a great team!

How to Automate Heroku App Deployment with GitLab CI/CD

Building and deploying LLM-based applications has never been easier. Since the launch and wide adoption of ChatGPT near the end of 2022, we’ve seen a storm of news about tools, products, and innovations stemming from large language models (LLMs) and generative AI (GenAI). While many tech fads come and go within a few years, it’s clear that are here to stay. LLMs and GenAI Do you ever wonder about all the tooling going on in the background behind many of these new tools and products? In addition, you might even ask yourself how these tools — leveraged by both developer and end users — are run in production. When you peel back the layers for many of these tools and applications, you’re likely to come across . LangChain, Python, and Heroku These are the pieces that we’re going to play around with in this article. We’ll look at a practical example of how AI/ML developers use them to build and easily deploy complex LLM pipeline components. Demystifying LLM Workflows and Pipelines Machine learning pipelines and workflows can seem like a black box for those new to the AI world. This is even more the case with LLMs and their related tools, as they’re such (relatively) new technologies. Working with LLMs can be challenging, especially as you’re looking to create engineering-hardened and production-ready pipelines, workflows, and deployments. With new tools, rapidly changing documentation, and limited instructions, knowing where to start or what to use can be hard. So, let’s start with the basics of LangChain and Heroku. The tells us this: “ ” documentation for LangChain LangChain is a framework for developing applications powered by language models. Meanwhile, this way: “ ” Heroku describes itself Heroku is a cloud platform that lets companies build, deliver, monitor, and scale apps — we’re the fastest way to go from idea to URL, bypassing all those infrastructure headaches. If we put this in the context of building an LLM application, then LangChain and Heroku are a match made in heaven. We need a well-tested and easy-to-use framework (LangChain) to build our LLM application, and then we need a way to deploy and host that application (Heroku). Let’s look into each of these technologies in more detail. Diving into LangChain Let’s briefly discuss how LangChain is used. LangChain is a framework that assists developers in building applications based on LLM models and use cases. It has support for , , and . For example, let’s say we were building a tool that generates reports based on user input or automates customer support response. LangChain acts as the scaffolding for our project, providing the tools and structure to efficiently integrate language models into our solution. Python JavaScript TypeScript Within LangChain, we have several key components: : The agent is the component that interacts with the language model to perform tasks based on our requirements. This is the brain of our application, using the capabilities of language models to understand and generate text. Agent : These are sequences of actions or processes that our agent follows to accomplish a task. For example, if we were automating customer support, a chain might include accepting a customer query, finding relevant information, and then crafting a response. Chains : Templates provide a way to structure the outputs from the language model. For example, if our application generates reports, then we would leverage a template that helps format these reports consistently based on the model’s output. Templates : This enables developers to up LangChain applications as a REST API. LangServe deploy and serve : This tool helps developers the interactions in their language model applications to get them ready for production. LangSmith evaluate, test, and refine LangChain is a widely adopted framework for building AI and LLM applications, and it’s easy to see why. LangChain provides the functionality to build and deploy products end-to-end. Diving into Heroku Heroku is best known as a cloud platform as a service (PaaS) which makes it incredibly simple to deploy applications to the cloud. Developers often want to focus solely on code and implementation. When you’re already dealing with complex data pipelines and LLM-based applications, you likely don’t have the resources or expertise to deal with infrastructure concerns like servers, networks, and persistent storage. With the ability to easily deploy your apps through Heroku, the major hurdle of production-izing your projects is handled effortlessly. Building with LangChain For a better understanding of how LangChain is used in an LLM application, let’s work through some example problems to make the process clear. In general, we would chain together the following pieces to form a single workflow for an LLM chain: Start with a to generate a prompt based on parameters from the user. prompt template Add a to the chain to retrieve data that the language model was not originally trained on (for example, from a database of documents). retriever Add a to include chat history so that the language model has context for formulating a better response. conversation retrieval chain Add an agent to interact with an actual LLM. LangChain lets us “chain” together the processes that form the base of an LLM application. This makes our implementation easy and approachable. Let’s work with a simple example. In our example, we’ll work with OpenAI. We’ll craft our prompt this way: Tell OpenAI to take on the persona of an encouraging fitness trainer. Input a question from the end user. To keep it nice and simple, we won’t worry about chaining in the retrieval of external data or chat history. Once you get the hang of LangChain, adding other capabilities to your chain is straightforward. On our local machine, we activate a virtual environment. Then, we install the packages we need: (venv) $ pip install langchain langchain_openai We’ll create a new file called . Our basic Python code looks like this: main.py import os
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

my_prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a friendly and encouraging fitness trainer."),
    ("user", "{input}")
])

llm = ChatOpenAI(openai_api_key=os.getenv("OPENAI_API_KEY"))

chain = my_prompt | llm That’s it! In this basic example, we’ve used LangChain to chain together a prompt template and our OpenAI agent. To use this from the command line, we would add the following code: user_input = input("Ask me a question related to your fitness goals.\n")
response = chain.invoke({
  "input": user_input
})

print(response) Let’s test out our application from the command line. (venv) $ OPENAI_API_KEY=insert-key-here python3 main.py 
Ask me a question related to your fitness goals.
How do I progress toward holding a plank for 60 seconds?
content="That's a great goal to work towards! To progress towards holding a plank for 
60 seconds, it's important to start with proper form and gradually increase the 
duration of your plank holds. Here are some tips to help you progress:\n\n1. Start 
with shorter durations: Begin by holding a plank for as long as you can with good 
form, even if it's just for a few seconds. Gradually increase the time as you get 
stronger.\n\n2. Focus on proper form: Make sure your body is in a straight line from 
head to heels, engage your core muscles, and keep your shoulders directly over your 
elbows.\n\n3. Practice regularly: Aim to include planks in your workout routine a few 
times a week. Consistency is key to building strength and endurance.\n\n4. Mix it up: 
Try different variations of planks, such as side planks or plank with leg lifts, to 
work different muscle groups and keep your workouts challenging.\n\n5. Listen to your 
body: It's important to push yourself, but also know your limits. If you feel any 
pain or discomfort, stop and rest.\n\nRemember, progress takes time and patience. 
Celebrate each milestone along the way, whether it's holding a plank for a few extra 
seconds or mastering a new plank variation. You've got this!" (I’ve added line breaks above for readability.) That’s a great start. But it would be nice if the output was formatted to be a bit more human-readable. To do that, we simply need to add an to our chain. We’ll use . output parser StrOutputParser import os
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
from langchain_core.output_parsers import StrOutputParser

my_prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a friendly and encouraging fitness trainer."),
    ("user", "{input}")
])

llm = ChatOpenAI(openai_api_key=os.getenv("OPENAI_API_KEY"))

chain = my_prompt | llm | output_parser

user_input = input("Ask me a question related to your fitness goals.\n")
response = chain.invoke({
  "input": user_input
})

print(response) Now, at the command line, our application looks like this: (venv) $ OPENAI_API_KEY=insert-key-here python3 main.py 
Ask me a question related to your fitness goals.
How do I learn how to do a pistol squat?
That's a great goal to work towards! Pistol squats can be challenging but with practice and patience, you can definitely learn how to do them.

Here are some steps you can follow to progress towards a pistol squat:

1. Start by improving your lower body strength with exercises like squats, lunges, and step-ups.
2. Work on your balance and stability by practicing single-leg balance exercises.
3. Practice partial pistol squats by lowering yourself down onto a bench or chair until you can eventually perform a full pistol squat.
4. Use a support like a TRX band or a pole to assist you with balance and lowering yourself down until you build enough strength to do it unassisted.

Remember to always warm up before attempting pistol squats and listen to your body to avoid injury. And most importantly, stay positive and patient with yourself as you work towards mastering this challenging exercise. You've got this! The LLM response is now formatted for improved readability. Our chains would be much more complex than this for building powerful LLM applications. But that’s the power and simplicity of LangChain. The framework allows for the modularity of logic specific to your needs so you can easily chain together complex workflows. Now that we have a simple LLM application built, we still need the ability to deploy, host, and serve our application to make it useful. As a developer focused on app building rather than infrastructure, we turn to LangServe and Heroku. Serving with LangServe LangServe helps us interact with a LangChain chain through a REST API. To write the serving portion of a LangChain LLM application, we need three key components: A valid chain ( ) like what we built above An API application framework (such as ) FastAPI Route definitions (just as we would have for building any sort of REST API) The provide some helpful examples of how to get up and running. For our example, we just need to use FastAPI to start up an API server and call from LangServe to make our chain accessible via API endpoints. LangServe docs add_routes() Along with this, we’ll need to make some minor modifications to our existing code. We’ll remove the use of the . This will give callers of our API flexibility in how they want to format and use the output. StrOutputParser We won’t prompt for user input from the command line. The API call request will provide the user’s input. We won’t call because LangServe will make this part of handling the API request. chain.invoke() We make sure to add the FastAPI and LangServe packages to our project: (venv) $ pip install langserve fastapi Our final file looks like this: main.py import os
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI
from fastapi import FastAPI
from langserve import add_routes

my_prompt = ChatPromptTemplate.from_messages([
    ("system", "You are a friendly and encouraging fitness trainer."),
    ("user", "{input}")
])

llm = ChatOpenAI(openai_api_key=os.getenv("OPENAI_API_KEY"))

chain = my_prompt | llm

app = FastAPI(title="Fitness Trainer"")

add_routes(app, chain)

if __name__ == "__main__":
    import uvicorn

    uvicorn.run(app, host="localhost", port=8000) On my local machine (Ubuntu 20.04.6 LTS) running Python 3.8.10, I also needed to install some additional packages to get rid of some warnings. You might not need to do this on your machine. (venv) $ pip install sse_starlette pydantic==1.10.13 Now, we start up our server: (venv) $ OPENAI_API_KEY=insert-key-here python3 main.py 

INFO:     Started server process [629848]
INFO:     Waiting for application startup.

LANGSERVE: Playground for chain "/" is live at:
LANGSERVE:  │
LANGSERVE:  └──> /playground/
LANGSERVE:
LANGSERVE: See all available routes at /docs/

INFO:     Application startup complete.
INFO:     Uvicorn running on http://localhost:8000 (Press CTRL+C to quit) Ooooh… nice! In the browser, we can go to . This is what we see: http://localhost:8000/docs LangServe serves up an API docs page that uses a Swagger UI! These are the endpoints now available to us through LangServe. We send a request to the endpoint. But LangServe also gives us a endpoint with a web interface to work with our chain directly. could POST invoke/ playground/ We provide input and click . Here’s the result: Start It’s important to stress the importance of having APIs in the context of LLM application workflows. If you think about it, most use cases of LLMs and applications built on top of them can’t rely on models and resources for inference. This neither makes sense nor scales well. local The real power of LLM applications is the ability to abstract away the complex workflow we’ve described so far. We want to put everything we’ve done behind an API so the use case can scale and others can integrate it. This is only possible if we have an easy option to host and serve these APIs. And that’s where Heroku comes in. Deploying to Heroku Heroku is the key, final part of our LLM application implementation. We have LangChain piece together our workflow, and LangServe will serve it up as a useful REST API. Now, instead of manually setting up complex resources to host and serve traffic, we turn to Heroku for the simple deployment of our application. After , we’re nearly ready to deploy. Let’s walk through the steps. setting up a Heroku account Create a new Heroku app Using the Heroku CLI, we log in and create a new app. $ heroku login
$ heroku create my-langchain-app Set config variables Next, we need to set the environment variable in our Heroku app environment. OPENAI_API_KEY $ heroku config:set OPENAI_API_KEY=replace-with-your-openai-api-key Create config files for Python application deployment To let Heroku know what we need for our Python application to run, we need to create three simple files: : Declares what command Heroku should execute to start our app. Procfile : Specifies the Python package dependencies that Heroku will need to install. requirements.txt : Specifies the exact version of the Python runtime we want to use for our app. runtime.txt These files are quick and easy to create. Each one goes into the project’s root folder. To create the , we run this command: Procfile $ echo 'web: uvicorn main:app --host=0.0.0.0 --port=${PORT}' > Procfile This tells Heroku to run , which is a web server implementation in Python. uvicorn For , we can use the command to output the list of installed packages. requirements.txt pip freeze $ pip freeze > requirements.txt Lastly, for , we will use Python 3.11.8. runtime.txt $ echo 'python-3.11.8' > runtime.txt With these files in place, our project root folder should look like this: $ tree
.
├── main.py
├── Procfile
├── requirements.txt
└── runtime.txt

0 directories, 4 files We commit all of these files to the GitHub repository. Connect Heroku to GitHub repo The last thing to do is for our GitHub repo and then push our code to the remote. Heroku will detect the push of new code and then deploy that code to our application. create a Heroku remote $ heroku git:remote -a my-langchain-app
$ git push heroku main When our code is pushed to the Heroku remote, Heroku builds the application, installs dependencies, and then runs the command in our . The final result of our command looks like this: Procfile git push …

remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote: 
remote: -----> Compressing...
remote:        Done: 71.8M
remote: -----> Launching...
remote:        Released v4
remote:        https://my-langchain-app-ea95419b2750.herokuapp.com/ deployed to Heroku
remote: 
remote: Verifying deploy... done. This shows the URL for our Heroku app. In our browser, we visit . https://my-langchain-app-ea95419b2750.herokuapp.com/playground We also check out our Swagger UI docs page at . https://my-langchain-app-ea95419b2750.herokuapp.com/docs And just like that, we’re up and running! This process is the best way to reduce developer time and overhead when working on large, complex LLM pipelines with LangChain. The ability to take APIs built with LangChain and seamlessly deploy to Heroku with a few simple command line arguments is what makes the pairing of LangChain and Heroku a no-brainer. Conclusion Businesses and developers today are right to ride the wave of AI and LLMs. There’s so much room for innovation and new development in these areas. However, the difference between the successes and failures will depend a lot on the toolchain they use to build and deploy these applications. Using the LangChain framework makes the process of building LLM-based applications approachable and repeatable. But, implementation is only half the battle. Once your application is built, you need the ability to easily and quickly deploy those application APIs into the cloud. That’s where you’ll have the advantage of faster iteration and development, and Heroku is a great way to get you there. Also published . here

Streamlining LLM Application Development and Deployment with LangChain, Heroku, and Python

Top Heroku Add-ons for App Development In 2024

2024 সালে অ্যাপ ডেভেলপমেন্টের জন্য সেরা Heroku অ্যাড-অন

Top Heroku-Add-ons für die App-Entwicklung im Jahr 2024

Principales complementos de Heroku para el desarrollo de aplicaciones en 2024

Meilleurs modules complémentaires Heroku pour le développement d'applications en 2024

2024 में ऐप डेवलपमेंट के लिए शीर्ष हेरोकू ऐड-ऑन

2024 年のアプリ開発向けのトップ Heroku アドオン

2024년 앱 개발을 위한 최고의 Heroku 추가 기능

Principais complementos Heroku para desenvolvimento de aplicativos em 2024

Лучшие дополнения Heroku для разработки приложений в 2024 году

2024'te Uygulama Geliştirme için En İyi Heroku Eklentileri

Các tiện ích bổ sung Heroku hàng đầu để phát triển ứng dụng vào năm 2024

2024 年应用程序开发的顶级 Heroku 附加组件

When deciding to own a house, you have two options. The first option would be to buy a fully built house, leaving you to decorate as you please. The second option is purchasing a plot of land, building from scratch, and handling interior decoration. If you need this house within a limited time, you will most likely choose the first option. In software development, that first option can be likened to . Platform as a Service Platform as a Service (PaaS) is a cloud computing model that provides developers with a platform to create, run, and manage applications without worrying about the complexity of underlying infrastructure management. With PaaS, developers can focus on application development and deployment. At the same time, the PaaS provider takes care of the underlying infrastructure, such as servers, storage, and networking, making it easier and faster to develop and deploy applications. PaaS providers offer developers a comprehensive environment for developing and deploying their software applications in the cloud. This cloud environment includes tools for building, deploying, and scaling applications. With these tools, developers can focus on delivering value without worrying about infrastructure. This article will discuss platform as a service and explore its software development benefits. In this article, you will learn about two PaaS providers - Aptible and Heroku, while highlighting their differences. At the end of this article, your development team will be able to make informed decisions about which PaaS provider best suits their application's needs. What Is PaaS? As earlier explained with the analogy, PaaS offers developers a fully equipped cloud environment to build applications without worrying about the infrastructure - servers, storage, and networking. house The entire infrastructure is delivered via the cloud, and developers only have to focus on writing the application code. PaaS helps companies avoid the expense and hassle of purchasing, setting up, and managing hardware and software needed for application development. These companies can subscribe to a PaaS provider and use the pay-as-you-go model, allowing them to only pay for the resources they use. Platform as a service is one of the three main categories of cloud computing services. Infrastructure as a Service and Software as a Service are two other cloud computing models. The table below shows the differences between these three categories. Category Description Examples Infrastructure as a Service (IaaS) IaaS is the most fundamental cloud computing service. When you use IaaS, you can rent servers, virtual machines, storage, networks, and operating systems from a cloud provider on a pay-as-you-go basis. Amazon Web Services (AWS), Google Compute Engine (GCE), Microsoft Azure, Platform as a Service (PaaS) PaaS platforms help developers build applications. PaaS providers typically include the same services as IaaS offerings but also high-level tools and components to help developers build applications faster. Aptible, Heroku, Google App Engine, Microsoft Azure, OpenShift. Software as a Service (SaaS) The SaaS model allows users to access software applications through the internet on a subscription basis, providing on-demand availability. Using SaaS, cloud providers offer hosting and infrastructure services and handle maintenance such as software updates and security patches. Users connect to the application over the internet, usually with a web browser on their phone, tablet, or PC. Google Workspace, Salesforce, Dropbox, MailChimp, DocuSign, Slack Benefits of PaaS In the fast-paced world of software development, utilizing platforms that allow you to focus on your core business is a no-brainer. PaaS offers a lot of benefits to developers and companies. Some of these benefits are: : Just like our fully built house analogy, PaaS offers development teams a platform that is always ready, updated, and scalable. Infrastructure availability : Companies can save costs by relying on PaaS platforms because they offer a pay-as-you-go model. This payment model allows companies to only pay for the resources they use, saving companies the cost of buying, configuring, and maintaining all the hardware and software. Cost savings : You would agree that buying an already-built house can save you the time it would take to build from scratch. In the same way, development teams could save a lot of time by using PaaS platforms. Reduced development time With a pre-built, up-to-date platform, you can focus on writing code and delivering value to your customers rather than worrying about the underlying infrastructure for your application. Aptible According to the analogy, we established that in order to own a house in the shortest amount of time, the best option would be to buy one. In this case, is that house. house Aptible Aptible is a PaaS that provides developers with a ready-to-use cloud environment for deploying their application or API. This cloud environment handles everything from scaling to database management and even metrics & logs of your application. Aptible, like every other PaaS, offers deployment, infrastructure scalability, and monitoring to development teams. However, Aptible's outstanding features are its commitment to reliability and security & compliance. Development teams have various options for deploying applications using Aptible. They can utilize the Aptible dashboard via the Graphic user interface, the command line interface, or even Infrastructure as Code - Terraform. Heroku If Aptible is the for developers looking for a ready-to-use cloud environment, then can be considered another impressive in the world of PaaS. go-to house Heroku property Heroku is another PaaS provider that lets companies build, deliver, monitor, and scale apps. It is a fully managed cloud platform with integrated data services and a powerful ecosystem for deploying and running modern web or mobile applications. Beyond apps, data lies at the heart of any significant application. Heroku recognizes this and provides a secure, scalable database-as-a-service with various developer tools. The goal is to offer developers immediate access to a scalable, highly available database that complements their development style. Comparison Between Aptible and Heroku By now, you should be convinced of the importance of PaaS and its relevance in software development. You should also have a good understanding of Aptible and Heroku. This section will compare both PaaS offerings and highlight their differences. Below is a table comparing Aptible and Heroku: Feature Aptible Heroku Service type Platform as a Service (PaaS) Platform as a Service (PaaS) Cloud environment Offers a cloud environment optimized for application and API deployment. Provides a cloud platform suitable for a wide range of applications and services. Deployment options Offers deployment options through the Aptible Dashboard, Command Line Interface (CLI), and Infrastructure as Code (Terraform). Provides deployment options through the "Deploy to Heroku" button, and Heroku CLI. Additionally, it also supports Git-based deployments for streamlined code management. Application scaling Supports application scaling for handling increased workloads. Allows applications to scale horizontally to accommodate growing user demands. Database management Offers support for database management within the cloud environment. Provides built-in database services and supports third-party databases for data storage. Monitoring Aptible offers application monitoring tools, ensuring they remain secure and operational. Heroku integrates monitoring and logging services, providing insights into application performance and stability. Integration with other services Integration options with external services are limited. Heroku offers an extensive ecosystem of add-ons and services that can seamlessly integrate with applications. Developer focus Places a strong emphasis on a developer-centric experience, aiming to simplify app deployment, management, and scaling. Offers a developer-centric platform that focuses on enabling developers to create applications efficiently with support for multiple programming languages. Language support Aptible supports various programming languages, enabling developers to work with their preferred language. Heroku is compatible with various programming languages, including Node.js, Ruby, Java, Python, and more, offering flexibility in language choice. Security & Compliance Prioritizes security and compliance, making it suitable for applications with strict security requirements. Maintains a security-focused approach, ensuring application and data security in the cloud environment. Scalability Suitable for businesses of various sizes, offering the capability to scale applications to meet specific requirements. Designed for scalability, Heroku is suitable for startups and enterprises, enabling seamless scaling of applications as they grow. Data services Aptible provides a rich ecosystem of managed data services, facilitating data management and storage for applications. Heroku offers a database-as-a-service approach with data management tools, enabling efficient data handling. Enterprise features Provides enterprise-level controls for advanced management and support for portfolios of applications. Offers enterprise-level support and features, making it suitable for large organizations with complex application needs. Pricing model Utilizes a subscription-based pricing model, making it predictable for budgeting. Adopts a flexible pricing model that allows businesses to pay only for the resources they consume. Integration with Salesforce Limited integration with Salesforce and other enterprise platforms. Provides seamless integration with Salesforce, enabling data synchronization and enhanced capabilities for CRM engagement. Although Aptible and Heroku are both PaaS offerings, these platforms differ. One of the most significant differences is that Aptible is specifically designed for companies that need to meet strict security & compliance requirements. Aptible complies with several industry standards, including HIPAA, PCI DSS, and SOC 2 Type II. On the other hand, Heroku is not explicitly designed for companies that need to meet these requirements. Another difference between Heroku and Aptible is that Aptible uses Docker containers to deploy applications. On the other hand, Heroku uses a buildpack system - a set of scripts used to compile applications and prepare them for deployment. Due to the buildpack system, developers are limited to the types of applications that can be deployed on Heroku. Aptible, on the other hand, allows developers to deploy applications written in any programming language. This feature makes Aptible a more flexible option regarding programming language support. Overall, Heroku and Aptible are both good PaaS providers that offer a variety of features to help developers deploy and manage their applications. The best platform for you will depend on your specific needs and requirements. If you are looking for a platform specifically designed for companies that must meet strict security and compliance requirements, then Aptible is an excellent option. If you are looking for a platform that is easy to use and offers various features, then Heroku is a good option to consider. Conclusion Building applications has never been easier with the aid of PaaS providers such as Aptible and Heroku. These platforms offer a variety of features to help developers deploy and manage their applications in ample time. It would be best to consider using a PaaS provider when deploying an application. Relying on PaaS can save you the time and stress of building and managing infrastructure simultaneously. You may also want to consider Aptible or Heroku, depending on what you specifically need and want. You can learn more about Aptible and Heroku by reading their documentation: Aptible Documentation Heroku Documentation You can also learn about PaaS by reading the following articles: What is Platform as a Service (PaaS)? Platform as a service (PaaS) Explained

PaaS: Aptible vs Heroku

Requirements Getting Started Setting up the basic structure Creating Task and User Models Creating endpoints and testing with Postman Deploying to Heroku The user and tasks models Code used in this article is AI generated. Disclaimer: Requirements To follow this tutorial, you'll need the following: Node.js installed on your computer A code editor like Visual Studio Code or Sublime Text A good understanding of JavaScript: The Fundamentals of JavaScript Getting started Create a new directory for your project and navigate to it in your terminal or command prompt: mkdir task-manager-app
cd task-manager-app Initialize a new Node.js project by running the following command: npm init This will create a new file in your project directory that contains information about your project and its dependencies. package.json Install the following packages by running the following commands: npm install express
npm install mongoose
npm install bcrypt
npm install jsonwebtoken
npm install dotenv
npm install multer These packages will help us build our task management application. Express is a popular Node.js web framework that provides a set of tools for building web applications, while Mongoose is an Object Data Modeling (ODM) library for MongoDB that provides a higher-level abstraction over the MongoDB Node.js driver. Bcrypt is a library for hashing passwords, while Jsonwebtoken is a library for creating and verifying JSON Web Tokens (JWTs). Dotenv is a zero-dependency module that loads environment variables from a file, and Multer is a middleware for handling file uploads. .env Create a new file called in your project directory and add the following environment variables: .env PORT=3000
MONGODB_URL=mongodb://localhost/task-manager
JWT_SECRET=mysecretkey This file will be used to store sensitive information like your MongoDB URL and JWT secret key. Setting up the Basic Structure for our Task Manager API Create a new directory called in your project directory. This will be the directory where you'll write your application code. src Create a new file called in the directory. This will be the entry point for your application. server.js src Open in your code editor and add the following code: server.js require('dotenv').config();
const express = require('express');
const mongoose = require('mongoose');
const bodyParser = require('body-parser');
const multer = require('multer');
const bcrypt = require('bcrypt');
const jwt = require('jsonwebtoken');

const app = express();
const port = process.env.PORT || 3000;

// Connect to MongoDB
mongoose.connect(process.env.MONGODB_URL, {
  useNewUrlParser: true,
  useUnifiedTopology: true,
  useCreateIndex: true,
  useFindAndModify: false
}).then(() => {
  console.log('Connected to MongoDB');
}).catch(error => {
  console.error(error);
});

// Middleware
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

// Routes
app.get('/', (req, res) => {
  res.send('Task Manager API');
});

// Start the server
app.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
}); This code sets up the basic structure for your application. It loads environment variables from the file using the package, sets up an Express app with some middleware, connects to MongoDB using Mongoose, and starts the server. .env dotenv Note that we're using the and packages for password hashing and authentication. We'll be using them later on when we build the authentication and authorization system for our application. bcrypt jsonwebtoken Creating Task and User Models Create a new file called in the directory. This file will define the model for our application. task.js src/models Task const mongoose = require('mongoose');

const taskSchema = new mongoose.Schema({
  title: {
    type: String,
    required: true
  },
  description: {
    type: String,
    required: true
  },
  completed: {
    type: Boolean,
    default: false
  },
  dueDate: {
    type: Date
  },
  owner: {
    type: mongoose.Schema.Types.ObjectId,
    required: true,
    ref: 'User'
  }
}, {
  timestamps: true
});

const Task = mongoose.model('Task', taskSchema);

module.exports = Task; This code defines a schema with the following properties: Task : A string that represents the title of the task. title : A string that represents the description of the task. description : A boolean that indicates whether the task is completed or not. completed : A date that represents the due date of the task. dueDate : A reference to the user who created the task. owner The option automatically adds and fields to the schema. timestamps createdAt updatedAt Create a new file called in the directory. This file will define the model for our application. user.js src/models User const mongoose = require('mongoose');
const validator = require('validator');
const bcrypt = require('bcrypt');
const jwt = require('jsonwebtoken');

const userSchema = new mongoose.Schema({
  name: {
    type: String,
    required: true,
    trim: true
  },
  email: {
    type: String,
    required: true,
    unique: true,
    trim: true,
    lowercase: true,
    validate(value) {
      if (!validator.isEmail(value)) {
        throw new Error('Invalid email address');
      }
    }
  },
  password: {
    type: String,
    required: true,
    trim: true,
    minlength: 6,
    validate(value) {
      if (value.toLowerCase().includes('password')) {
        throw new Error('Password cannot contain "password"');
      }
    }
  },
  tokens: [{
    token: {
      type: String,
      required: true
    }
  }]
}, {
  timestamps: true
});

userSchema.virtual('tasks', {
  ref: 'Task',
  localField: '_id',
  foreignField: 'owner'
});

userSchema.methods.toJSON = function () {
  const user = this.toObject();

  delete user.password;
  delete user.tokens;

  return user;
};

userSchema.methods.generateAuthToken = async function () {
  const user = this;
  const token = jwt.sign({ _id: user._id.toString() }, process.env.JWT_SECRET);

  user.tokens = user.tokens.concat({ token });
  await user.save();

  return token;
};

userSchema.statics.findByCredentials = async (email, password) => {
  const user = await User.findOne({ email });

  if (!user) {
    throw new Error('Invalid email or password');
  }

  const isMatch = await bcrypt.compare(password, user.password);

  if (!isMatch) {
    throw new Error('Invalid email or password');
  }

  return user;
};

userSchema.pre('save', async function (next) {
  const user = this;

  if (user.isModified('password')) {
    user.password = await bcrypt.hash(user.password, 8);
  }

  next();
});

const User = mongoose.model('User', userSchema);

module.exports = User; This code defines a schema with the following properties: User : A string that represents the name of the user. name : A string that represents the email address of the user. email : A string that represents the password of the user. password : An array of authentication tokens for the user. tokens The method creates a virtual property on the user model that references the tasks owned by the user. virtual The method is used to remove the and fields from the user object before sending it to the client. toJSON password tokens The method generates a JWT token and adds it to the user's array. generateAuthToken tokens The method is used to find a user by email and password. findByCredentials The middleware is used to hash the password before saving it to the database. pre Creating Endpoints for our NodeJS MongoDB API Now that we have defined the model, we can create the endpoints for our API. Let's create a new file called in the directory. In this file, we will define the routes for creating a new user, logging in a user, and logging out a user. User user.js src/routes const express = require('express');
const User = require('../models/user');
const auth = require('../middleware/auth');

const router = new express.Router();

// Create a new user
router.post('/users', async (req, res) => {
  const user = new User(req.body);

  try {
    await user.save();
    const token = await user.generateAuthToken();
    res.status(201).send({ user, token });
  } catch (e) {
    res.status(400).send(e);
  }
});

// Login user
router.post('/users/login', async (req, res) => {
  try {
    const user = await User.findByCredentials(req.body.email, req.body.password);
    const token = await user.generateAuthToken();
    res.send({ user, token });
  } catch (e) {
    res.status(400).send(e);
  }
});

// Logout user
router.post('/users/logout', auth, async (req, res) => {
  try {
    req.user.tokens = req.user.tokens.filter((token) => {
      return token.token !== req.token;
    });
    await req.user.save();
    res.send();
  } catch (e) {
    res.status(500).send(e);
  }
});

module.exports = router; Let's go over what each of these routes does: : Creates a new user in the database. The user's information is sent in the request body. If the user is created successfully, the API returns the user's information and a JWT token. POST /users : Logs in a user with their email and password. If the login is successful, the API returns the user's information and a JWT token. POST /users/login : Logs out the current user by removing their current authentication token from the array in the database. The user must be authenticated to access this route, which is why we use the middleware. POST /users/logout tokens auth Now that we have our user routes, let's create the task routes. Create a new file called in the directory. task.js src/routes const express = require('express');
const Task = require('../models/task');
const auth = require('../middleware/auth');

const router = new express.Router();

// Create a new task
router.post('/tasks', auth, async (req, res) => {
  const task = new Task({
    ...req.body,
    owner: req.user._id
  });

  try {
    await task.save();
    res.status(201).send(task);
  } catch (e) {
    res.status(400).send(e);
  }
});

// Get all tasks
router.get('/tasks', auth, async (req, res) => {
  try {
    const tasks = await Task.find({ owner: req.user._id });
    res.send(tasks);
  } catch (e) {
    res.status(500).send(e);
  }
});

// Get a task by id
router.get('/tasks/:id', auth, async (req, res) => {
  const _id = req.params.id;

  try {
    const task = await Task.findOne({ _id, owner: req.user._id });

    if (!task) {
      return res.status(404).send();
    }

    res.send(task);
  } catch (e) {
    res.status(500).send(e);
// Update a task by id
router.patch('/tasks/:id', auth, async (req, res) => {
  const updates = Object.keys(req.body);
  const allowedUpdates = ['description', 'completed'];
  const isValidOperation = updates.every((update) => allowedUpdates.includes(update));

  if (!isValidOperation) {
    return res.status(400).send({ error: 'Invalid updates!' });
  }

  try {
    const task = await Task.findOne({ _id: req.params.id, owner: req.user._id });

    if (!task) {
      return res.status(404).send();
    }

    updates.forEach((update) => task[update] = req.body[update]);
    await task.save();
    res.send(task);
  } catch (e) {
    res.status(400).send(e);
  }
});

// Delete a task by id
router.delete('/tasks/:id', auth, async (req, res) => {
  try {
    const task = await Task.findOneAndDelete({ _id: req.params.id, owner: req.user._id });

    if (!task) {
      return res.status(404).send();
    }

    res.send(task);
  } catch (e) {
    res.status(500).send(e);
  }
});

module.exports = router; Here's what each of these routes does: : Creates a new task in the database. The task's information is sent in the request body. The field of the task is set to the ID of the authenticated user. Only authenticated users can access this route. POST /tasks owner : Retrieves all tasks from the database that belong to the authenticated user. GET /tasks : Retrieves a task by its ID from the database if it belongs to the authenticated user. GET /tasks/:id : Updates a task by its ID with the specified fields in the request body. Only the and fields can be updated. Only authenticated users can update their own tasks. PATCH /tasks/:id description completed : Deletes a task by its ID if it belongs to the authenticated user. DELETE /tasks/:id Now that we have our routes defined, let's modify index.js to use them: const express = require('express');
require('./db/mongoose');
const userRouter = require('./routes/user');
const taskRouter = require('./routes/task');

const app = express();
const port = process.env.PORT || 3000;

app.use(express.json());
app.use(userRouter);
app.use(taskRouter);

app.listen(port, () => {
  console.log(`Server is up on port ${port}`);
}); Testing Endpoints with Postman or cURL We're now ready to test our API! You can use tools like Postman or cURL to test the endpoints we defined above. For example, you can create a new user by sending a POST request to with a JSON body like this: http://localhost:3000/users {
  "name": "John Doe",
  "email": "johndoe@example.com",
  "password": "password123"
} You should receive a response with the newly created user's information and a JWT token. Next, you can use the token to create a new task by sending a POST request to with a JSON body like this: http://localhost:3000/tasks {
  "description": "Buy groceries"
} You should receive a response with the newly created task's information. Finally, you can retrieve all of the user's tasks by sending a GET request to with the JWT token in the `Authorization http://localhost:3000/tasks Now that we have our API up and running, let's take a look at how we can deploy it to a production environment. Deployment to a Production Environment There are many ways to deploy a Node.js application to a production environment, but one of the most popular ways is to use a Platform as a Service (PaaS) provider like Heroku or AWS Elastic Beanstalk. In this tutorial, we'll be using Heroku to deploy our application. Heroku Heroku is a cloud platform that allows you to deploy, manage, and scale your applications. To use Heroku, you'll need to create an account and install the Heroku CLI on your computer. Once you've done that, you can use the following commands to deploy your application: First, create a new Heroku application by running the following command: heroku create This will create a new Heroku application and add a new remote to your local Git repository. Next, push your code to the Heroku remote by running the following command: git push heroku main This will deploy your application to Heroku. Finally, start your application by running the following command: heroku ps:scale web=1 This will start a single instance of your application on Heroku. That's it! Your application should now be live on Heroku. Environment Variables When deploying your application to a production environment, it's important to keep your secrets (like database passwords and JWT secrets) secure. One way to do this is to use environment variables. To use environment variables in your application, you can use the package. This package allows you to store your environment variables in a file in your project directory, which is ignored by Git. To use , install it by running the following command: dotenv .env dotenv npm install dotenv Then, create a new file called in your project directory and add your environment variables like this: .env PORT=3000
MONGODB_URL=mongodb://localhost:27017/task-manager-api
JWT_SECRET=mysecretkey Finally, modify to use the package: index.js dotenv require('dotenv').config();
const express = require('express');
require('./db/mongoose');
const userRouter = require('./routes/user');
const taskRouter = require('./routes/task');

const app = express();
const port = process.env.PORT || 3000;

app.use(express.json());
app.use(userRouter);
app.use(taskRouter);

app.listen(port, () => {
  console.log(`Server is up on port ${port}`);
}); Now, when you deploy your application to a production environment, you can set your environment variables using the provider's interface (for example, Heroku allows you to set environment variables using the Heroku Dashboard or the Heroku CLI). Conclusion In this tutorial, we've covered a lot of ground! We started by building a simple Node.js application that uses Express, Mongoose, and JWT authentication to manage tasks for users. Then, we added more advanced features like middleware, file uploads, and error handling. Finally, we deployed our application to a production environment using Heroku. There's a lot more to learn about Node.js and web development in general, but hopefully, this tutorial has given you a good starting point. I'd love to connect with you via & Twitter LinkedIn Happy coding!

Building a Task Manager API with NodeJS, Express, MongoDB, and Heroku

117 Stories To Learn About Heroku

Webhooks are a powerful tool for integrating different applications and services. They allow one application to send real-time notifications to another application by making an HTTP request to a specific URL endpoint. This article will provide a brief guide on creating a webhook URL in three popular cloud platforms: AWS, Heroku, and GCP. We will show you how to create a webhook endpoint in each platform and how to access it to receive incoming requests. We will also discuss some of the considerations you should keep in mind, such as enabling CORS for cross-origin requests. Here’s a table: Platform Steps AWS 1. Sign in to your AWS account and go to the API Gateway page. 2. Click on the "Create API" button. 3. In the next window, give your API a name and choose the "Webhook" option as the protocol. 4. Create a new resource for your API. 5. Create a method for your new resource. 6. Your webhook URL is now ready to receive requests. Heroku 1. Sign in to your Heroku account and go to the dashboard. 2. Click on the "New" button and select "Create new app". 3. In the next window, give your app a name and select a region. 4. Deploy your webhook endpoint to the app. 5. Your webhook URL is now ready to receive requests. GCP 1. Sign in to your GCP account and go to the Cloud Functions page. 2. Click on the "Create Function" button. 3. In the next window, give your function a name and select "HTTP" as the trigger type. 4. Write the code for your webhook endpoint. 5. Deploy your webhook endpoint to GCP. 6. Your webhook URL is now ready to receive requests. More specifically: You will need to use the to create a webhook URL in AWS. Here is a brief guide on how to do this: AWS API Gateway Sign in to your AWS account and go to the API Gateway page. Click on the "Create API" button. This will open a new window where you can specify the details of your API. In the next window, give your API a name and choose the "Webhook" option as the protocol. Then click on the "Create API" button. Next, you will need to create a new resource for your API. This will be the URL endpoint that will receive the webhook requests. To do this, click on the "Actions" dropdown menu and select "Create Resource". In the next window, give your resource a name and select "POST" as the HTTP method. Then click on the "Create Resource" button. Now, you will need to create a method for your new resource. This will be the actual webhook URL that will receive the incoming requests. To do this, click on the "Actions" dropdown menu and select "Create Method". Select "POST" as the HTTP method in the next window and click on the "Integration Type" dropdown menu. Select "HTTP" as the integration type and enter the URL of the webhook endpoint in the "Endpoint URL" field. Then click on the "Save" button. Your webhook URL is now ready to receive requests. You can test it by sending a POST request to the URL using a tool like Postman. To create a webhook URL in , you will need to create a new app in your Heroku account and deploy a webhook endpoint to it. Here is a brief guide on how to do this: Heroku Sign in to your Heroku account and go to the dashboard. Click on the "New" button and select "Create new app". In the next window, give your app a name and select a region. Then click on the "Create app" button. Next, you will need to deploy your webhook endpoint to the app. To do this, you will need to have a webhook endpoint written in a programming language that is supported by Heroku (such as Node.js or Python). Once you have your webhook endpoint code, you can deploy it to Heroku using the Heroku CLI (Command Line Interface) or by connecting your app to a GitHub repository and deploying it from there. Once your webhook endpoint is deployed, you can access it at the URL https://[your-app-name].herokuapp.com/[endpoint-path], where [your-app-name] is the name of your app and [endpoint-path] is the path of the endpoint within your app (for example, /webhook). To create a webhook URL in , you will need to use the Cloud Functions service. Here is a brief guide on how to do this: GCP (Google Cloud Platform) Sign in to your GCP account and go to the Cloud Functions page. Click on the "Create Function" button. This will open a new window where you can specify the details of your function. In the next window, give your function a name and select "HTTP" as the trigger type. This will make the function execute when it receives an HTTP request. Then click on the "Create" button. Next, you will need to write the code for your webhook endpoint. This function will process the incoming HTTP request and return a response. You can use any of the languages supported by Cloud Functions, such as Node.js, Python, or Go. Once you have written your webhook endpoint code, you can deploy it to GCP by clicking on the "Deploy" button in the Cloud Functions editor. Your webhook URL is now ready to receive requests. You can access it at the URL https://[region]-[project-id].cloudfunctions.net/[function-name], where [region] is the region where your function is deployed, [project-id] is the ID of your GCP project, and [function-name] is the name of your function. You may need to enable CORS (Cross-Origin Resource Sharing) for your webhook URL if you want to receive requests from other websites. To do this, you must add the appropriate CORS headers to the response returned by your webhook endpoint. You can find more information on how to do this in the documentation for the language that you are using for your webhook endpoint. In conclusion, creating a webhook URL in AWS, Heroku, or GCP is a straightforward process that can be accomplished with just a few steps. By following the instructions in this article, you can quickly set up a webhook endpoint that will allow you to receive real-time notifications from other applications and services. With a webhook URL in place, you can easily integrate your application with many other platforms and services, unlocking new possibilities for automation and interoperability.

Creating a Webhook URL: A Guide for AWS, Heroku, and GCP

is one of the most beloved companies on the internet for me and for many others. However, many feel orphaned due to their decision to . Heroku terminate their free products Some other free or cheap services can replace part of Heroku’s free products, but what about having your own hosting solution for your apps on the cloud for free? I'm going to show you how to do that by installing , a free, self-hosted, alternative to Heroku, on an VM, step by step. Dokku Oracle Cloud Requirements An . Oracle offers, at the time of this writing, two free VMs per user. It can be a trial account or a standard one. We are only going to use Oracle Cloud account free resources. with ssh keys installed; git An you can deploy to Dokku (something you would deploy to Heroku); app A you own (we are going to call it ); domain <your-domain-name> A drink and a snack. 1  -  Creating the VM Go to , click . Give it a name. Compute → Instances Create Instance Go to Select for the image. For the shape, select Image and Shape. Canonical Ubuntu, version 18.04 VM.Standard.E2.1.Micro; Go to Select the existing and . Create one if you don’t have one already. Choose Networking. Primary Network Subnet Assign Public IP Address; Go to . Either generate a key pair (requires installing them on your system), upload or paste your own public key; Add SSH Keys Click . Wait until the VM finishes provisioning (the orange box turns to green); Create On the VM page, click on the link to your ( ); subnet Primary VNIC section Click on the on the panel; Default Security List Security Lists Check if there are for ports 80 and 443 (likely not); Ingress Rules Create an with the following settings: Ingress Rule Stateless: CheckedSource Type: CIDRSource CIDR: 0.0.0.0/0IP Protocol: TPCSource Port Range: leave blank Destination Port Range: 80,443 Description: HTTP(s) 2 - Installing Dokku Now return to the Instances page and copy your VM's (we are going to call it from now on); Public ID <public-ip> Open a terminal; SSH into the VM with (if asked if you want to continue, type yes); ssh ubuntu@<public-ip> Run the following commands (depending on when you are doing this, it may be wise to check Dokku’s website for updated commands): wget https://raw.githubusercontent.com/dokku/dokku/v0.28.1/bootstrap.sh
sudo DOKKU_TAG=v0.28.1 bash bootstrap.sh Wait while Dokku is installed, this will take around 5 to 8 minutes; Open your ssh public key on a text file (or on the terminal) and copy its contents. Let's call them . Then run the next command: <CONTENTS_OF_ID_RSA_PUB_FILE> echo '<CONTENTS_OF_ID_RSA_PUB_FILE>' | sudo dokku ssh-keys:add admin 3 - Setting up Global Domains Remember that we talked about? It's the domain you are going to use as the global domain for your Dokku installation. Now run the following commands: <your-domain-name> dokku domains:clear-global
dokku domains:add-global <your-domain-name> Now may also be a good time to set up your domain's DNS fields. I'm using Namecheap and I just had to create two (* and @) pointing to . A fields <public-ip> 4 - Creating your first app We are going to create our first app on Dokku and deploy it from our local computer. I'm using a basic Sinatra app, but you can use any technology supported by Dokku (Rails, Django, Node, PHP. The list goes on). I'm gonna call this app Starter. You can use any name you want (let's call it . Run the following command: <your-app-name> dokku apps:create <your-app-name> 5 - Deploying your app Depending on the stack you are using, there may be different requirements for your deployment. In my case, I'm using so I need to have a config.ru file or a PROCFILE. You may also need (and want even if not needed) to install (you can use Heroku's buildpacks which are open source). Please check Dokku documentation about that. Sinatra buildpacks With a terminal in your project folder, setup git: git init
git add .
git commit -m "create app"
git remote add dokku dokku@<public-ip>:<your-app-name>
git push dokku master The app will be created with the default subdomain of . For instance: if your app is called starter and your domain example.com, the app domain will be . But you can point your domain name directly to the app with the command (in our case: ). That way our app would be visible directly on . <your-app-name>.<your-domain-name> starter.example.com dokku domains:add <your-app-name> <your-domain-name> dokku domains:add starter example.com example.com 6 - Accepting web requests on your VM Opening the ports on the network isn't enough. You need to enable web traffic on the VM's (at least for Oracle Cloud’s version of Ubuntu 18.04): iptables sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -P FORWARD ACCEPT
sudo iptables -F 7 - Enabling SSL with Letsencrypt Run the following commands: sudo dokku plugin:install https://github.com/dokku/dokku-letsencrypt.git
dokku config:set --no-restart <your-app-name> DOKKU_LETSENCRYPT_EMAIL=<your-email-address>
dokku letsencrypt:enable <your-app-name> If you run into errors you may want to try and retry sudo service docker restart dokku letsencrypt:enable <your-app-name> And now your app should be up and running on https://<your-app-name>.<your-domain-name> The End And that's all for now. You should be able to run one reasonably sized app on this VM or multiple smaller apps. You can install buildpacks for databases (like Postgresql) and connect your apps to them. Oracle Cloud provides two free VMs so you can play a little bit with it. VM.Standard.E2.1.Micro Of course, if you consider using this kind of hosting for serious apps, you will probably want to go with a stronger VM and robust services around it. Sources / Further Reading Getting Started with Dokku - Dokku Documentation https://stackoverflow.com/questions/54794217/opening-port-80-on-oracle-cloud-infrastructure-compute-node Free Tier: Install Apache and PHP on an Ubuntu Instance

Build a Free Personal Heroku with Oracle Cloud and Dokku

Migrating from Heroku to the Qoddi App Platform is very easy and requires a small amount of time. This guide will guide you in the process of moving your app from Heroku to Qoddi, including databases, Redis, and Docker containers. Some add-ons are not (yet) available on Qoddi, like the Sparkpost email sending library, and may need to be included in your code using the language library. We do our best to onboard third-party add-ons on Qoddi as quickly as possible. Qoddi works seamlessly with GitHub and supports most Heroku build packs. The main difference between Qoddi and Heroku is that Qoddi doesn’t require any configuration file or CLI to use, everything is managed from the Qoddi dashboard. Pre-requisites Create a free account at https://qoddi.com Add a valid credit card to your account Migration Steps Understanding the difference between Qoddi and Heroku infrastructures Create your app on Qoddi Configure Environment variables Install Adminer to import data to PostgreSQL and import data Update DNS configuration Troubleshoot the build process Understanding the differences between Qoddi and Heroku infrastructures The way Qoddi and Heroku host your apps and route data inside the network is fairly different. Here’s what you need to be aware of before starting: Qoddi’s infrastructure uses a modern, serverless implementation. Only web data can reach your apps, no matter the port used. Pay attention to the port your app uses to be reachable from the Internet and use the same port inside your app settings on Qoddi (that can be 80,8080, 3306, or whatever port your choose to use). Qoddi’s internal network always routes the traffic depending on what your app needs. For instance, it will never route web queries to a database, and all the internal traffic is encrypted. Datastores created on Qoddi cannot be reached from the Internet, meaning you can’t connect to your PostgreSQL database on Qoddi from an app hosted elsewhere; this is by design and applicable to all datastores (including Redis). Create your App on Qoddi From the Qoddi dashboard click +, choose the size and location of your app, and connect your GitHub repository. You can also select a datastore (Postgres if coming from Heroku) directly during the app creation phase, your app will have all the parameters to connect to the database automatically set up. Configure Environment Variables It’s critical to keep all sensitive information inside the Environment Variables instead of your code (like database passwords or third-party keys). Qoddi doesn’t support .env files and requires that all environment variables be created from the Qoddi Dashboard. Install Adminer add-on for Postgres and Import Data Adminer is a free app available on Qoddi’s Marketplace to manage your PostgreSQL database. Click “Marketplace” from the Qoddi dashboard and launch Adminer inside the same stack of your database (if the database is created) Adminer is created as a Web App inside the same stack and can be accessed using Qoddi’s URL. To connect to your Postgres database, check the internal name, username, and password from the database settings page: Use the same value to connect to your database using Adminer: And voila! From Adminer you can import your . SQL file from Heroku. Note: You can use Adminer to connect to your Heroku PostgreSQL app directly from Qoddi to export your SQL file. Update DNS configuration Note: this feature is not available for Free apps Add your domain name to your Qoddi app : Copy the CNAME record and create a CNAME from your DNS provider ( ) : here’s a detailed procedure Troubleshoot the build process Visit the Deploy tab of your app to see the last deployment and access the build log. This will give you a detailed view of the build process and, if the build failed, the exact reason. The log tab can also be helpful if your app doesn’t start. Most of cases, it’s because the app port used by your code is different than the one set up by default on Qoddi; adjusting the app port will fix this issue. If you have any issues, don’t delete your app yet! Most of cases, it’s an easy fix; contact ! us Also Published here

How to Migrate Your Apps From Heroku to Qoddi

Heroku's been taking it on the chin lately for their response to what looks to be a pretty-damn-serious security incident—and for good reason because about the whole event has been . their communication abysmal Personally, this is a pretty big letdown, because I've been riding the for quite some time. As a software developer with a history of working for teeny-tiny startups (in addition to a fair amount of freelancing), Heroku's Platform-as-a-Service Solution(PaaS) —has been a lifesaver for all the cool kids out there. Heroku train When you're crunched for time and resources, offloading things like server maintenance, security, database management, and all the other that accompany running a software company is incredibly valuable; and Heroku's add-on marketplace is just icing on the cake. tasks Trust me, there's nothing more satisfying than spinning up all the internal and external resources you need within a single pane of glass. As a freelancer, this sort of organization makes billing clients (and eventually transferring application ownership) a snap. Heroku Alternatives But... all of that is gone now. It has been outweighed by a complete and total lack of trust in a company that I've historically put a of trust in. As a result, I've been exploring a few Heroku alternatives that are all new to the PaaS space (or, at least, relatively new to ). lot relatively me To be clear, I'm skipping the most well-known solutions like 's App Platform and 's App Engine, because I think most people are already aware of them, so flogging that particular horse is probably just a waste of bits and bytes. DigitalOcean Google Cloud That said, I've stumbled across a handful of solutions that are both unique pretty "indie" feeling—a great combination in the "tools by developers, for developers" category if you ask me. awesome and Fly.io I've heard of a few times over the years, but it wasn't until just the last few days that I've really taken the opportunity to try it out; and, I've got to say, it's pretty damn awesome. Fly.io While not nearly as "feature robust" as Heroku (read: no "marketplace"), it is a Docker-driven solution with an generous free tier, and one of the most impressive commitments to technical writing I've ever seen (which, if I'm being honest, is only outshone by DigitalOcean's approach). incredibly As the founder of , I personally own and manage any of the integrations and websites that we rely on, and have chosen Fly.io as our new destination. The transition from Heroku to Fly.io was about as painless as you could imagine, and the terminal-driven management has been a great experience. The MUD Coders Guild If you are on the fence and don't have a huge application footprint, you definitely can't go wrong with Fly. Render is a new solution for me, but it most closely resembles Heroku as far as features and functionality go (although that isn't to imply that it is no better than Heroku). A winner in the 2019 TechCrunch Startup Battlefield (an event I will forever associate with Pied Piper and Middle-Out Encryption thanks to HBO's ), Render offers all the bells and whistles that we've come to expect in a PaaS platform: Render Silicon Valley Autoscaling Managed databases Preview environments Docker deployments And cron support actual I have yet to dig deeply into it, but will likely be moving some of my more complicated freelance projects over to Render when the opportunity presents itself (and, just as an aside, their free tier is about as generous as you can ask for). too Porter I've examined in the past as part of an roundup for TechTarget and liked what I saw. Porter Open Source PaaS really What sets Porter apart from the other solutions on this list is that it is an open-source self-hosted option. While they do offer a managed cloud solution that relies on your backend infrastructure, the self-hosted option is super compelling as it gives you total control over your infrastructure. and own While I am personally not in the "manage all my things" game, this is an excellent solution for people who are looking to make the leap from hosting PaaS to managing their own infrastructure. Conclusion Obviously, there are a hell of a lot more platform-as-a-service providers out there than just these three. From big to small, proprietary to open source, it's a pretty big space. That said, these three are the more compelling ones in my mind, and I will be watching them as they continue to grow. If these don't quite fit your needs and are looking for more options to try, take a look at this . There are some great solutions available. Awesome-PaaS list Also published at . flower.codes

Try these 3 Alternatives to Heroku

When building projects one of the annoying parts is setting up stuff like web servers, relational databases, caching, etc. It’s often expensive (Heroku charges $25/month for their 1GB instance, the same server is 5/month on DigitalOcean) or tedious to set up and manage. I no longer enjoy spending hours and days setting up a server, building tools, sending code to the server, building it, getting an SSL certificate, installing it, update nginx over and over again whenever I have a new project. That’s where open-source PAASs came in. They often have an extremely easy-to-use app/database deployment & web server manager. Examples: , , etc. CapRover Dokku For example, with CapRover, you can host the below with one click: Databases and Database GUIs. Eg PostgreSQL, Redis, MySQL, MongoDB, etc. Email hosting, newsletter & mailing list solutions. Customer support, CMSs, ERPs, CRMs, LMSs & Invoicing solutions. Analytics Blogging and Content. Eg: Ghost, Jekyll, WordPress, etc. CI/CD Dev tools (monitoring, notifications, URL shorteners, backups, etc) Cloud storage, FTP & media servers Torrent clients Document servers (text documents, spreadsheets & presentations) And more wrapped in a Docker container Literally anything Requirements: Own a domain. Have some familiarity with the Cloud, Linux and Docker. Get server & install Docker Set up an Ubuntu VPS Good providers: (Free ) https://cloud.google.com/free/docs/gcp-free-tier/#compute (Free if you can to sign up lol) https://www.oracle.com/ke/cloud/free/#always-free manage https://contabo.com/en/vps/ https://www.netcup.eu/vserver/vps.php#v-server-details https://www.ovhcloud.com/en/vps/compare/ https://www.racknerd.com/kvm-vps https://www.hetzner.com/cloud Create VPS Instance I’ll be using the free virtual machine ( ) from Google Cloud Platform. Feel free to use any other. Compute Engine In GCP Create an Ubuntu instance from the . GCP Dashboard Configure Firewall Add firewall rules to allow network traffic from the following: 80 TCP for regular HTTP connections 443 TCP for secure HTTPS connections 3000 TCP for initial Installation (can be blocked once attached to a domain) 7946 TCP/UDP for Container Network Discovery 4789 TCP/UDP for Container Overlay Network 2377 TCP/UDP for Docker swarm API 996 TCP for secure HTTPS connections specific to Docker Registry In case of an ubuntu server, run ufw allow 80,443,3000,996,7946,4789,2377/tcp; ufw allow 7946,4789,2377/udp; Your VPS provider may have a different way to configure the firewall. In GCP In the case of GCP, we can create firewall rules from the : Networking Dashboard Note that I’ve created a network tag that we’ll use next. caprover From the , edit the virtual machine we created, adding the network tag. Compute Engine dashboard caprover Install Docker SSH into the VM and install Docker. This can be done using the get : convenience script curl -fsSL https://get.docker.com -o get-docker.sh

sudo sh get-docker.sh Sample output: Set up CapRover Install CapRover on the server Run the following to install CapRover: sudo docker run -p 80:80 -p 443:443 -p 3000:3000 -v /var/run/docker.sock:/var/run/docker.sock -v /captain:/captain caprover/caprover NOTE: do not change the port mappings. CapRover only works on the specified ports. You will see a bunch of outputs on your screen. Once the CapRover is initialised, you can visit in your browser and log in to CapRover using the default password . You can change your password later. However, do not make any changes in the dashboard. We'll use the command-line tool to set up the server. http://[IP_OF_YOUR_SERVER]:3000 captain42 Set up DNS Let's say you own . Set as an in your DNS settings to point to the IP address of the server where you installed CapRover. mydomain.com *.something.mydomain.com A-record Find more info . here Install CapRover CLI on your local machine npm install -g caprover Complete CapRover Setup & log in to the Dashboard Complete CapRover Setup Run the following on your local machine: caprover serversetup Follow the steps and log in to your CapRover instance. When prompted to enter the root domain, enter assuming that you set to point to your IP address in step #Set up DNS. Now you can access your CapRover from and log in. something.mydomain.com *.something.mydomain.com captain.something.mydomain.com Log in to the Dashboard Visit the CapRover dashboard at and log in using the password you set up in the above step. http://captain.something.mydomain.com Install the One-Click Apps from the Dashboard Sources and More Information https://caprover.com/docs/get-started.html#step-1-caprover-installation https://cloud.google.com/compute/docs

Stories, News & Mentions about HEROKU

Heroku’s Stories on HackerNoon

Heroku's News & Mentions