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

How to Deploy a Scala Play Application to Heroku

.NET developers now have access to the officially supported buildpack for .NET, which means you can now deploy your .NET apps onto Heroku with just one command: git push heroku main. 🤯 Gone are the days of searching for Dockerfiles or community buildpacks. With official support, .NET developers can now run any .NET application (version 8.0 and higher) on the Heroku platform. Being on the platform means you also get: Simple, low friction deployment
Scaling and service management
Access to the add-on ecosystem
Security and governance features for enterprise use Intrigued? Let’s talk about what this means for .NET developers. Why This Matters for .NET Developers In my experience, running an app on Heroku is pretty easy. But deploying .NET apps was an exception. You could deploy on Heroku, but there wasn’t official support. One option was to wrap your app in a Docker container. This meant creating a Dockerfile and dealing with all the maintenance that comes along with that approach. Alternatively, you could find a third-party buildpack; but that introduced another dependency into your deployment process, and you’d lose time trying to figure out which community buildpack was the right one for you. Needing to use these workarounds was unfortunate, as Heroku’s seamless deployment is supposed to make it easy to create and prototype new apps. Now, with official buildpack support, the deployment experience for .NET developers is smoother and more reliable. Key Benefits of .NET on Heroku The benefits of the new update center around simplicity and scalability. It all begins with simple deployment. Just one git command… and your deployment begins. No need to start another workflow or log into another site every time; just push your code from the command line, and Heroku takes care of the rest. Heroku’s official .NET support currently includes C#, Visual Basic, and F# projects for .NET and ASP.NET Core frameworks (version 8.0 and higher). This means that a wide variety of .NET projects are now officially supported. Want to deploy a Blazor app alongside your ASP.NET REST API? You can do that now. Coming into the platform also means you can scale as your app grows. If you need to add another service using a different language, you can deploy that service just as easily as your original app. Or you can easily scale your dynos to match peak load requirements. This scaling extends to Heroku’s ecosystem of add-ons, making it easy for you to add value to your application with supporting services while keeping you and your team focused on your core application logic. In addition to simple application deployment, the platform also supports more advanced CI/CD and DevOps needs. With Heroku Pipelines, you have multiple deployment environment support options and can set up review apps so code reviewers can access a live version of your app for each pull request. And all of this integrates tightly with GitHub, giving you automatic deployment triggers to streamline your dev flow. Getting Started Let’s do a quick walk-through on how to get started. In addition to your application and Git, you will also need the Heroku CLI installed on your local machine. Initialize the CLI with the heroku login command. This will take you to a browser to log into your Heroku account: Once you’re logged in, navigate to your .NET application folder. In that folder, run the following commands: ~/project$ heroku create~/project$ heroku buildpacks:add heroku/dotnet Now, you’re ready to push your app! You just need one command to go live: ~/project$ git push heroku main That’s it! For simpler .NET applications, this is all you need. Your application is now live at the app URL provided in the response to your heroku create command. To see it again, you can always use heroku info. Or, you can run heroku open to launch your browser at your app URL. If you can’t find the URL, log in to the Heroku Dashboard. Find your app and click on Open app. You’ll be redirected to your app URL. If you have a more complex application or one with multiple parts, you will need to define a Procfile, which will tell Heroku how to start up your application. Don’t be intimidated! Many Procfiles are just a couple lines. For more in-depth information, check out the Getting Started on Heroku with .NET guide. Now we’ve got another question to tackle… Who Should Care? The arrival of .NET on Heroku is relevant to anyone who wants to deploy scalable .NET services and applications seamlessly. For solo devs and startups, the platform’s low friction and scaling takes away the burden of deployment and hosting. This allows small teams to focus on building out their core application logic. These teams are also not restricted by their app’s architecture, as Heroku supports both large single-service applications as well as distributed microservice apps. Enterprise teams are poised to benefit from this as well. .NET has historically found much of its adoption in the enterprise, and the addition of official support for .NET to Heroku means that these teams can now combine their .NET experience with the ease of deploying to the Heroku platform. Heroku’s low friction enables rapid prototyping of new applications, and Dyno Formations make it easier to manage and scale a microservice architecture. Additionally, you can get governance through Heroku Enterprise, enabling the security and controls that larger enterprises require. Finally, .NET enthusiasts from all backgrounds and skill levels can now benefit from this new platform addition. By going with a modern PaaS, you can play around with apps and projects of all sizes, hassle-free. Wrap-up That’s a brief introduction to official .NET support on Heroku! It’s now easier than ever to deploy .NET applications of all sizes to Heroku. What are you going to build and deploy first? Let me know in the comments! .NET developers now have access to the officially supported buildpack for .NET , which means you can now deploy your .NET apps onto Heroku with just one command: git push heroku main . 🤯 Gone are the days of searching for Dockerfiles or community buildpacks. With official support, .NET developers can now run any .NET application (version 8.0 and higher) on the Heroku platform. officially supported buildpack for .NET officially supported buildpack for .NET git push heroku main Being on the platform means you also get: Simple, low friction deployment Scaling and service management Access to the add-on ecosystem Security and governance features for enterprise use Simple, low friction deployment Scaling and service management Access to the add-on ecosystem Security and governance features for enterprise use Intrigued? Let’s talk about what this means for .NET developers. Why This Matters for .NET Developers In my experience, running an app on Heroku is pretty easy. But deploying .NET apps was an exception. You could deploy on Heroku, but there wasn’t official support. One option was to wrap your app in a Docker container. This meant creating a Dockerfile and dealing with all the maintenance that comes along with that approach. Alternatively, you could find a third-party buildpack; but that introduced another dependency into your deployment process, and you’d lose time trying to figure out which community buildpack was the right one for you. Dockerfile Needing to use these workarounds was unfortunate, as Heroku’s seamless deployment is supposed to make it easy to create and prototype new apps. Now, with official buildpack support, the deployment experience for .NET developers is smoother and more reliable. Key Benefits of .NET on Heroku The benefits of the new update center around simplicity and scalability. It all begins with simple deployment . Just one git command… and your deployment begins. No need to start another workflow or log into another site every time; just push your code from the command line, and Heroku takes care of the rest. simple deployment git Heroku’s official .NET support currently includes C#, Visual Basic, and F# projects for .NET and ASP.NET Core frameworks (version 8.0 and higher). This means that a wide variety of .NET projects are now officially supported. Want to deploy a Blazor app alongside your ASP.NET REST API? You can do that now. official .NET support official .NET support Blazor app Coming into the platform also means you can scale as your app grows. If you need to add another service using a different language, you can deploy that service just as easily as your original app. Or you can easily scale your dynos to match peak load requirements. This scaling extends to Heroku’s ecosystem of add-ons , making it easy for you to add value to your application with supporting services while keeping you and your team focused on your core application logic. scale add-ons In addition to simple application deployment, the platform also supports more advanced CI/CD and DevOps needs. With Heroku Pipelines , you have multiple deployment environment support options and can set up review apps so code reviewers can access a live version of your app for each pull request. And all of this integrates tightly with GitHub, giving you automatic deployment triggers to streamline your dev flow. CI/CD and DevOps Heroku Pipelines Heroku Pipelines review apps review apps Getting Started Let’s do a quick walk-through on how to get started. In addition to your application and Git, you will also need the Heroku CLI installed on your local machine. Initialize the CLI with the heroku login command. This will take you to a browser to log into your Heroku account: Heroku CLI Heroku CLI heroku login Once you’re logged in, navigate to your .NET application folder. In that folder, run the following commands: ~/project$ heroku create~/project$ heroku buildpacks:add heroku/dotnet ~/project$ heroku create~/project$ heroku buildpacks:add heroku/dotnet ~/project$ heroku create~/project$ heroku buildpacks:add heroku/dotnet ~/project$ heroku create~/project$ heroku buildpacks:add heroku/dotnet ~/project$ heroku create ~/project$ heroku buildpacks:add heroku/dotnet Now, you’re ready to push your app! You just need one command to go live: ~/project$ git push heroku main ~/project$ git push heroku main ~/project$ git push heroku main ~/project$ git push heroku main ~/project$ git push heroku main That’s it! For simpler .NET applications, this is all you need. Your application is now live at the app URL provided in the response to your heroku create command. To see it again, you can always use heroku info . Or, you can run heroku open to launch your browser at your app URL. heroku create heroku info heroku open If you can’t find the URL, log in to the Heroku Dashboard . Find your app and click on Open app . You’ll be redirected to your app URL. Heroku Dashboard Heroku Dashboard Open app If you have a more complex application or one with multiple parts, you will need to define a Procfile , which will tell Heroku how to start up your application. Don’t be intimidated! Many Procfiles are just a couple lines. For more in-depth information, check out the Getting Started on Heroku with .NET guide . Procfile Procfile Getting Started on Heroku with .NET guide Getting Started on Heroku with .NET guide Now we’ve got another question to tackle… Who Should Care? The arrival of .NET on Heroku is relevant to anyone who wants to deploy scalable .NET services and applications seamlessly. For solo devs and startups , the platform’s low friction and scaling takes away the burden of deployment and hosting. This allows small teams to focus on building out their core application logic. These teams are also not restricted by their app’s architecture, as Heroku supports both large single-service applications as well as distributed microservice apps. solo devs and startups Enterprise teams are poised to benefit from this as well. .NET has historically found much of its adoption in the enterprise, and the addition of official support for .NET to Heroku means that these teams can now combine their .NET experience with the ease of deploying to the Heroku platform. Heroku’s low friction enables rapid prototyping of new applications, and Dyno Formations make it easier to manage and scale a microservice architecture. Additionally, you can get governance through Heroku Enterprise , enabling the security and controls that larger enterprises require. Enterprise teams Dyno Formations Dyno Formations Heroku Enterprise Heroku Enterprise Finally, . NET enthusiasts from all backgrounds and skill levels can now benefit from this new platform addition. By going with a modern PaaS, you can play around with apps and projects of all sizes, hassle-free. NET enthusiasts Wrap-up That’s a brief introduction to official .NET support on Heroku! It’s now easier than ever to deploy .NET applications of all sizes to Heroku. What are you going to build and deploy first? Let me know in the comments!

Heroku Now Officially Supports .NET!

When creating a new app or service, what begins as learning just one new tool can quickly turn into needing a whole set of tools and frameworks. For Python devs, jumping into HTML, CSS, and JavaScript to build a usable app can be daunting. For web devs, many Python-first backend tools work in JavaScript but are often outdated. You’re left with a choice: Stick with JavaScript or switch to Python for access to the latest features. FastHTML bridges the gap between these two groups. For Python devs, it makes creating a web app straightforward—no JavaScript required! For web devs, it makes creating a Python app quick and easy, with the option to extend using JavaScript—you’re not locked in. As a web developer, I’m always looking for ways to make Python dev more accessible. So, let’s see how quickly we can build and deploy a FastHTML app. I’ll follow the image generation tutorial and then deploy it to Heroku. Let’s go! Intro to FastHTML Never heard of FastHTML before? Here’s how FastHTML describes itself: FastHTML is a new next-generation web framework for fast, scalable web applications with minimal, compact code. It’s designed to be:


Powerful and expressive enough to build the most advanced, interactive web apps you can imagine.


Fast and lightweight, so you can write less code and get more done.


Easy to learn and use, with a simple, intuitive syntax that makes it easy to build complex apps quickly. FastHTML promises to enable you to generate usable, lightweight apps quickly. Too many web apps are bloated and heavy, requiring a lot of processing and bandwidth for simple tasks. Most web apps just need something simple, beautiful, and easy to use. FastHTML aims to make that task easy. You may have heard of FastAPI, designed to make creating APIs with Python a breeze. FastHTML is inspired by FastAPI’s philosophy, seeking to do the same for frontend applications. Opinionated About Simplicity and Ease of Use Part of the FastHTML vision is to “make it the easiest way to create quick prototypes, and also the easiest way to create scalable, powerful, rich applications.” As a developer tool, FastHTML seems to be opinionated about the right things—simplicity and ease of use without limiting you in the future. FastHTML gets you up and running quickly while also making it easy for your users. It does this by selecting key core technologies such asASGI and HTMX. The foundations page from FastHTML introduces these technologies and gives the basics (though you don’t need to know about these to get started). Get Up and Running Quickly The tutorials from FastHTML offer several examples of different apps, each with its own use case. I was curious about the Image Generation App tutorial and wanted to see how quickly I could get a text-to-image model into a real, working app. The verdict? It was fast. Really fast. In less than 60 lines of code, I created a fully functioning web app where a user can type in a prompt and receive an image from the free Pollinations text-to-image model. Here’s a short demo of the tutorial app: In this tutorial app, I got a brief glimpse of the power of FastHTML. I learned how to: Submit data through a form
Interact with external APIs
Display some loading text while waiting What’s impressive is that it only took one tiny Python file to complete this, and the final app is lightweight and looks good. Here’s the file I ended up with: from fastcore.parallel import threaded
from fasthtml.common import *
import os, uvicorn, requests, replicate
from PIL import Image

app = FastHTML(hdrs=(picolink,))

# Store our generations
generations = []
folder = f"gens/"
os.makedirs(folder, exist_ok=True)

# Main page
@app.get("/")
def home():
    inp = Input(id="new-prompt", name="prompt", placeholder="Enter a prompt")
    add = Form(Group(inp, Button("Generate")), hx_post="/", target_id='gen-list', hx_swap="afterbegin")
    gen_list = Div(id='gen-list')
    return Title('Image Generation Demo'), Main(H1('Magic Image Generation'), add, gen_list, cls='container')

# A pending preview keeps polling this route until we return the image preview
def generation_preview(id):
    if os.path.exists(f"gens/{id}.png"):
        return Div(Img(src=f"/gens/{id}.png"), id=f'gen-{id}')
    else:
        return Div("Generating...", id=f'gen-{id}', 
                   hx_post=f"/generations/{id}",
                   hx_trigger='every 1s', hx_swap='outerHTML')
    
@app.post("/generations/{id}")
def get(id:int): return generation_preview(id)
    

# For images, CSS, etc.
@app.get("/{fname:path}.{ext:static}")
def static(fname:str, ext:str): return FileResponse(f'{fname}.{ext}')

# Generation route
@app.post("/")
def post(prompt:str):
    id = len(generations)
    generate_and_save(prompt, id)
    generations.append(prompt)
    clear_input =  Input(id="new-prompt", name="prompt", placeholder="Enter a prompt", hx_swap_oob='true')
    return generation_preview(id), clear_input

# URL (for image generation)  
def get_url(prompt): 
    return f"https://image.pollinations.ai/prompt/{prompt.replace(' ', '%20')}?model=flux&width=1024&height=1024&seed=42&nologo=true&enhance=true"

@threaded
def generate_and_save(prompt, id):
    full_url = get_url(prompt)
    Image.open(requests.get(full_url, stream=True).raw).save(f"{folder}/{id}.png")
    return True

if __name__ == '__main__': uvicorn.run("app:app", host='0.0.0.0', port=int(os.getenv("PORT", default=5000))) Looking for more functionality? The tutorial continues, adding some CSS styling, user sessions, and even payment tracking with Stripe. While I didn’t go through it all the way, the potential is clear: lots of functionality and usability without a lot of boilerplate or using both Python and JavaScript. Deploy Quickly to Heroku Okay, so now that I have a pure Python app running locally, what do I need to do to deploy it? Heroku makes this easy. I added a single file called Procfile with just one line in it: web: python app.py This simple text file tells Heroku how to run the app. With the Procfile in place, I can use the Heroku CLI to create and deploy my app. And it’s fast…from zero to done in less than 45 seconds. With two commands, I created my project, built it, and deployed it to Heroku. And let’s just do a quick check. Did it actually work? And it’s up for the world to see! Conclusion When I find a new tool that makes it easier and quicker to build an app, my mind starts spinning with the possibilities. If it’s that easy, then maybe next time I need to spin up something, I can do it this way and integrate it with this tool, and that other thing… So much of programming is assembling the right tools for the job. FastHTML has opened the door to a whole set of Python-based applications for me, and Heroku makes it easy to get those apps off my local machine and into the world. That said, several of the foundations of FastHTML are new to me, and I look forward to understanding them more deeply as I use them more. I hope you have fun with FastHTML and Heroku! Happy coding! When creating a new app or service, what begins as learning just one new tool can quickly turn into needing a whole set of tools and frameworks. For Python devs, jumping into HTML, CSS, and JavaScript to build a usable app can be daunting. For web devs, many Python-first backend tools work in JavaScript but are often outdated. You’re left with a choice: Stick with JavaScript or switch to Python for access to the latest features. FastHTML bridges the gap between these two groups. For Python devs, it makes creating a web app straightforward—no JavaScript required! For web devs, it makes creating a Python app quick and easy, with the option to extend using JavaScript—you’re not locked in. FastHTML As a web developer, I’m always looking for ways to make Python dev more accessible. So, let’s see how quickly we can build and deploy a FastHTML app. I’ll follow the image generation tutorial and then deploy it to Heroku . Let’s go! image generation tutorial Heroku Intro to FastHTML Never heard of FastHTML before? Here’s how FastHTML describes itself : how FastHTML describes itself FastHTML is a new next-generation web framework for fast, scalable web applications with minimal, compact code. It’s designed to be: Powerful and expressive enough to build the most advanced, interactive web apps you can imagine.


Fast and lightweight, so you can write less code and get more done.


Easy to learn and use, with a simple, intuitive syntax that makes it easy to build complex apps quickly. FastHTML is a new next-generation web framework for fast, scalable web applications with minimal, compact code. It’s designed to be: Powerful and expressive enough to build the most advanced, interactive web apps you can imagine. Fast and lightweight, so you can write less code and get more done. Easy to learn and use, with a simple, intuitive syntax that makes it easy to build complex apps quickly. Powerful and expressive enough to build the most advanced, interactive web apps you can imagine. Powerful and expressive enough to build the most advanced, interactive web apps you can imagine. Fast and lightweight, so you can write less code and get more done. Fast and lightweight, so you can write less code and get more done. Easy to learn and use, with a simple, intuitive syntax that makes it easy to build complex apps quickly. Easy to learn and use, with a simple, intuitive syntax that makes it easy to build complex apps quickly. FastHTML promises to enable you to generate usable, lightweight apps quickly. Too many web apps are bloated and heavy, requiring a lot of processing and bandwidth for simple tasks. Most web apps just need something simple, beautiful, and easy to use. FastHTML aims to make that task easy. You may have heard of FastAPI , designed to make creating APIs with Python a breeze. FastHTML is inspired by FastAPI’s philosophy, seeking to do the same for frontend applications. FastAPI Opinionated About Simplicity and Ease of Use Part of the FastHTML vision is to “make it the easiest way to create quick prototypes, and also the easiest way to create scalable, powerful, rich applications.” As a developer tool, FastHTML seems to be opinionated about the right things—simplicity and ease of use without limiting you in the future. FastHTML vision FastHTML gets you up and running quickly while also making it easy for your users. It does this by selecting key core technologies such as ASGI and HTMX . The foundations page from FastHTML introduces these technologies and gives the basics (though you don’t need to know about these to get started). ASGI HTMX foundations Get Up and Running Quickly The tutorials from FastHTML offer several examples of different apps, each with its own use case. I was curious about the Image Generation App tutorial and wanted to see how quickly I could get a text-to-image model into a real, working app. The verdict? It was fast. Really fast. Image Generation App tutorial In less than 60 lines of code, I created a fully functioning web app where a user can type in a prompt and receive an image from the free Pollinations text-to-image model. Pollinations Here’s a short demo of the tutorial app: In this tutorial app, I got a brief glimpse of the power of FastHTML. I learned how to: Submit data through a form Interact with external APIs Display some loading text while waiting Submit data through a form Interact with external APIs Display some loading text while waiting What’s impressive is that it only took one tiny Python file to complete this, and the final app is lightweight and looks good. Here’s the file I ended up with: from fastcore.parallel import threaded
from fasthtml.common import *
import os, uvicorn, requests, replicate
from PIL import Image

app = FastHTML(hdrs=(picolink,))

# Store our generations
generations = []
folder = f"gens/"
os.makedirs(folder, exist_ok=True)

# Main page
@app.get("/")
def home():
    inp = Input(id="new-prompt", name="prompt", placeholder="Enter a prompt")
    add = Form(Group(inp, Button("Generate")), hx_post="/", target_id='gen-list', hx_swap="afterbegin")
    gen_list = Div(id='gen-list')
    return Title('Image Generation Demo'), Main(H1('Magic Image Generation'), add, gen_list, cls='container')

# A pending preview keeps polling this route until we return the image preview
def generation_preview(id):
    if os.path.exists(f"gens/{id}.png"):
        return Div(Img(src=f"/gens/{id}.png"), id=f'gen-{id}')
    else:
        return Div("Generating...", id=f'gen-{id}', 
                   hx_post=f"/generations/{id}",
                   hx_trigger='every 1s', hx_swap='outerHTML')
    
@app.post("/generations/{id}")
def get(id:int): return generation_preview(id)
    

# For images, CSS, etc.
@app.get("/{fname:path}.{ext:static}")
def static(fname:str, ext:str): return FileResponse(f'{fname}.{ext}')

# Generation route
@app.post("/")
def post(prompt:str):
    id = len(generations)
    generate_and_save(prompt, id)
    generations.append(prompt)
    clear_input =  Input(id="new-prompt", name="prompt", placeholder="Enter a prompt", hx_swap_oob='true')
    return generation_preview(id), clear_input

# URL (for image generation)  
def get_url(prompt): 
    return f"https://image.pollinations.ai/prompt/{prompt.replace(' ', '%20')}?model=flux&width=1024&height=1024&seed=42&nologo=true&enhance=true"

@threaded
def generate_and_save(prompt, id):
    full_url = get_url(prompt)
    Image.open(requests.get(full_url, stream=True).raw).save(f"{folder}/{id}.png")
    return True

if __name__ == '__main__': uvicorn.run("app:app", host='0.0.0.0', port=int(os.getenv("PORT", default=5000))) from fastcore.parallel import threaded
from fasthtml.common import *
import os, uvicorn, requests, replicate
from PIL import Image

app = FastHTML(hdrs=(picolink,))

# Store our generations
generations = []
folder = f"gens/"
os.makedirs(folder, exist_ok=True)

# Main page
@app.get("/")
def home():
    inp = Input(id="new-prompt", name="prompt", placeholder="Enter a prompt")
    add = Form(Group(inp, Button("Generate")), hx_post="/", target_id='gen-list', hx_swap="afterbegin")
    gen_list = Div(id='gen-list')
    return Title('Image Generation Demo'), Main(H1('Magic Image Generation'), add, gen_list, cls='container')

# A pending preview keeps polling this route until we return the image preview
def generation_preview(id):
    if os.path.exists(f"gens/{id}.png"):
        return Div(Img(src=f"/gens/{id}.png"), id=f'gen-{id}')
    else:
        return Div("Generating...", id=f'gen-{id}', 
                   hx_post=f"/generations/{id}",
                   hx_trigger='every 1s', hx_swap='outerHTML')
    
@app.post("/generations/{id}")
def get(id:int): return generation_preview(id)
    

# For images, CSS, etc.
@app.get("/{fname:path}.{ext:static}")
def static(fname:str, ext:str): return FileResponse(f'{fname}.{ext}')

# Generation route
@app.post("/")
def post(prompt:str):
    id = len(generations)
    generate_and_save(prompt, id)
    generations.append(prompt)
    clear_input =  Input(id="new-prompt", name="prompt", placeholder="Enter a prompt", hx_swap_oob='true')
    return generation_preview(id), clear_input

# URL (for image generation)  
def get_url(prompt): 
    return f"https://image.pollinations.ai/prompt/{prompt.replace(' ', '%20')}?model=flux&width=1024&height=1024&seed=42&nologo=true&enhance=true"

@threaded
def generate_and_save(prompt, id):
    full_url = get_url(prompt)
    Image.open(requests.get(full_url, stream=True).raw).save(f"{folder}/{id}.png")
    return True

if __name__ == '__main__': uvicorn.run("app:app", host='0.0.0.0', port=int(os.getenv("PORT", default=5000))) Looking for more functionality? The tutorial continues, adding some CSS styling, user sessions, and even payment tracking with Stripe. While I didn’t go through it all the way, the potential is clear: lots of functionality and usability without a lot of boilerplate or using both Python and JavaScript. Deploy Quickly to Heroku Okay, so now that I have a pure Python app running locally, what do I need to do to deploy it? Heroku makes this easy. I added a single file called Procfile with just one line in it: Procfile web: python app.py web: python app.py This simple text file tells Heroku how to run the app. With the Procfile in place, I can use the Heroku CLI to create and deploy my app. And it’s fast…from zero to done in less than 45 seconds. Heroku CLI With two commands, I created my project, built it, and deployed it to Heroku. And let’s just do a quick check. Did it actually work? And it’s up for the world to see! Conclusion When I find a new tool that makes it easier and quicker to build an app, my mind starts spinning with the possibilities. If it’s that easy, then maybe next time I need to spin up something, I can do it this way and integrate it with this tool, and that other thing… So much of programming is assembling the right tools for the job. FastHTML has opened the door to a whole set of Python-based applications for me, and Heroku makes it easy to get those apps off my local machine and into the world. That said, several of the foundations of FastHTML are new to me, and I look forward to understanding them more deeply as I use them more. I hope you have fun with FastHTML and Heroku! Happy coding!

FastHTML and Heroku: What You Need to Know

Playwright and Chrome Browser Testing in Heroku: A Beginner's Guide

Heroku ukan dramaturgo ukat Chrome Navegador ukan yant’awipa: Qalltirinakatakix mä guia

Heroku-da dramaturq və Chrome Brauzer Testi: Başlayanlar üçün Bələdçi

Testiranje dramaturga i Chrome pretraživača u Heroku: Vodič za početnike

Pruebas del navegador Chrome y Playwright en Heroku: una guía para principiantes

Tès otè ak navigatè Chrome nan Heroku: Gid pou yon debutan

Heroku での Playwright と Chrome ブラウザのテスト: 初心者向けガイド

Тестирање на драматург и на прелистувачот Chrome во Heroku: водич за почетници

Penulis drama dan Ujian Penyemak Imbas Chrome dalam Heroku: Panduan Pemula

Testimi i dramaturgut dhe i shfletuesit Chrome në Heroku: Një udhëzues fillestar

Jaribio la Playwright na Kivinjari cha Chrome katika Heroku: Mwongozo wa Wanaoanza

การทดสอบนักเขียนบทละครและเบราว์เซอร์ Chrome ใน Heroku: คู่มือสำหรับผู้เริ่มต้น

Dramaturg va Chrome brauzerini Heroku’da sinovdan o‘tkazish: yangi boshlanuvchilar uchun qo‘llanma

 Wow, pnpm, You're Really Fast: How to Use It on Heroku

 Vaja, pnpm, sou molt ràpid: com utilitzar-lo a Heroku

Vaya, pnpm, eres muy rápido: cómo usarlo en Heroku

 وای، pnpm، شما واقعاً سریع هستید: نحوه استفاده از آن در Heroku

 וואו, pnpm, אתה ממש מהיר: איך להשתמש בו ב-Heroku

すごい、pnpm、本当に速いですね: Heroku での使い方

 Wah, pnpm, Anda Sungguh Pantas: Cara Menggunakannya pada Heroku

 Uau, pnpm, ești cu adevărat rapid: cum să-l folosești pe Heroku

 Wow, pnpm, Ju jeni vërtet i shpejtë: Si ta përdorni atë në Heroku

ว้าว pnpm คุณเร็วจริงๆ: วิธีใช้งานบน Heroku

 Wow, pnpm, U Hatlisa Hakunene: Ndlela Yo Yi Tirhisa Eka Heroku

 Voy, pnpm, siz juda tezsiz: uni Heroku-da qanday ishlatish kerak

Wow, pnpm, Bạn thực sự nhanh: Cách sử dụng nó trên Heroku

Custom Domains for HTTP/2 on Heroku — It's So easy!

Effortlessly Deploy Django Apps to the Cloud with GitHub Actions and Heroku

In our last two articles, we explored how to configure CI/CD for Heroku using Heroku pipelines. When viewing a pipeline within the Heroku dashboard, you can easily start a deployment or promote your code from one environment to the next with the click of a button. From the dashboard, you can monitor the deployment and view its progress. This all works really well, assuming that you have Heroku open in your browser. But, what if you wanted to do it all from Slack? Software engineers use a lot of apps at work. Throughout the day, we are constantly bouncing between Zoom meetings, Jira tasks, Slack conversations, GitHub, email, our calendar, and our IDE. This context switching can be exhausting and also lead to a lot of visual clutter on our monitors. Sometimes, it’s nice to just live in Slack, and that’s why many tools offer Slack integrations. With these Slack integrations, you can monitor various processes and even use shortcut commands to trigger actions. Heroku ChatOps, the Heroku Slack integration, allows you to start and monitor deployments directly from Slack. In this article, we’ll explore some of the Slack commands it offers. Getting Started If you’d like to follow along throughout this tutorial, 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 that we will use with our Heroku pipeline in this article is deployed to Heroku, and the code is hosted on GitHub. Create Our Heroku Pipeline We won’t go through the step-by-step process of creating a Heroku pipeline in this article. Refer to these articles for a walkthrough of creating a Heroku pipeline: How to create a Heroku pipeline with a staging and production app and a single main branch
How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch You can also read the Heroku docs for Heroku pipelines. Configuring your Heroku pipeline includes the following steps: Create a GitHub repo.
Create a Heroku pipeline.
Connect the GitHub repo to the Heroku pipeline.
Add a staging app to the pipeline.
Add a production app to the pipeline. The other activities that you’ll see in those articles, such as configuring review apps, Heroku CI, or automated deployments are optional. In fact, for the purposes of this demo, I recommend not configuring automated deployments, since we’ll be using some Slack commands to start the deployments. When you’re done, you should have a Heroku pipeline that looks something like this: Connect to Slack Now that you have your Heroku pipeline created, it’s time for the fun part: integrating with Slack. You can install the Heroku ChatOps Slack app here. Clicking that link will prompt you to grant the Heroku ChatOps app permission to access your Slack workspace: After that, you can add the Heroku ChatOps app to any Slack channel in your workspace. After adding the app, type /h login and hit Enter. This will prompt you to connect your Heroku and GitHub accounts. You’ll see several Heroku OAuth and GitHub OAuth screens where you confirm connecting these accounts. (As a personal anecdote, I found that it took me several tries to connect my Heroku account and my GitHub account. It may be due to having several Slack workspaces to choose from, but I’m not sure.) After connecting your Heroku account and your GitHub account, you’re ready to start using Heroku in Slack. View All Pipelines To view all deployable pipelines, you can type /h pipelines: View Pipeline Info To see information about any given pipeline, type /h info <PIPELINE_NAME>. (Anything you see in angle brackets throughout this article should be replaced by an actual value. In this case, the value would be the name of a pipeline — for example, “heroku-flow-demo-pipeline”.) View Past Releases To view a history of past releases for any given pipeline, type /h releases <PIPELINE_NAME>. This command defaults to showing you past releases for the production app, so if you want to see the past releases for the staging app, you can type /h releases <PIPELINE_NAME> in <STAGE_NAME>, where <STAGE_NAME> is “staging.” Deploy to Staging Now that we know which pipelines are available, we can see information about any given pipeline along with when the code was last released for that pipeline. We’re ready to trigger a deployment. Most engineering organizations have a Slack channel (or channels) where they monitor deployments. Imagine being able to start a deployment right from that channel and monitor it as it goes out! That’s exactly what we’ll do next. To start a deployment to your staging environment, type /h deploy <PIPELINE_NAME> to <STAGE_NAME>, where <STAGE_NAME> is “staging.” After running that command, an initial message is posted to communicate that the app is being deployed. Shortly after, you’ll also see several more messages; this time, in a Slack thread on the original message: If you want to verify what you’re seeing in Slack, you can always check the Heroku pipeline in your Heroku dashboard. You’ll see the same information: The staging app has been deployed! Promote to Production Now, let’s promote our app to production. Without the Slack commands, we could navigate to our Heroku pipeline, click the “Promote to production” button, and then confirm that action in the modal dialog that appears. However, we’d prefer to stay in Slack. To promote the app to production from Slack, type /h promote <PIPELINE_NAME>. Just like with the staging deployment, an initial Slack message will be sent, followed by several other messages as the production deployment goes out: And — voilà — the latest changes to the app are now in production! Conclusion Now, you can start and monitor Heroku app deployments all from Slack — no need to context switch or move between multiple apps. For more use cases and advanced setups, you can also check out the docs. Happy deploying! In our last two articles, we explored how to configure CI/CD for Heroku using Heroku pipelines . When viewing a pipeline within the Heroku dashboard, you can easily start a deployment or promote your code from one environment to the next with the click of a button. From the dashboard, you can monitor the deployment and view its progress. configure CI/CD for Heroku using Heroku pipelines start a deployment or promote your code from one environment to the next This all works really well, assuming that you have Heroku open in your browser. But, what if you wanted to do it all from Slack? Software engineers use a lot of apps at work. Throughout the day, we are constantly bouncing between Zoom meetings, Jira tasks, Slack conversations, GitHub, email, our calendar, and our IDE. This context switching can be exhausting and also lead to a lot of visual clutter on our monitors. Sometimes, it’s nice to just live in Slack, and that’s why many tools offer Slack integrations. With these Slack integrations, you can monitor various processes and even use shortcut commands to trigger actions. Heroku ChatOps , the Heroku Slack integration, allows you to start and monitor deployments directly from Slack. In this article, we’ll explore some of the Slack commands it offers. Heroku ChatOps Getting Started If you’d like to follow along throughout this tutorial, 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 that we will use with our Heroku pipeline in this article is deployed to Heroku, and the code is hosted on GitHub . the code is hosted on GitHub Create Our Heroku Pipeline We won’t go through the step-by-step process of creating a Heroku pipeline in this article. Refer to these articles for a walkthrough of creating a Heroku pipeline: How to create a Heroku pipeline with a staging and production app and a single main branch How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch How to create a Heroku pipeline with a staging and production app and a single main branch How to create a Heroku pipeline with a staging and production app and a single main branch How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch How to create a Heroku pipeline with a staging and production app with a dev branch and a main branch You can also read the Heroku docs for Heroku pipelines . Heroku docs for Heroku pipelines Configuring your Heroku pipeline includes the following steps: Create a GitHub repo. Create a Heroku pipeline. Connect the GitHub repo to the Heroku pipeline. Add a staging app to the pipeline. Add a production app to the pipeline. Create a GitHub repo. Create a Heroku pipeline. Connect the GitHub repo to the Heroku pipeline. Add a staging app to the pipeline. Add a production app to the pipeline. The other activities that you’ll see in those articles, such as configuring review apps, Heroku CI, or automated deployments are optional. In fact, for the purposes of this demo, I recommend not configuring automated deployments, since we’ll be using some Slack commands to start the deployments. not When you’re done, you should have a Heroku pipeline that looks something like this: Connect to Slack Now that you have your Heroku pipeline created, it’s time for the fun part: integrating with Slack. You can install the Heroku ChatOps Slack app here . install the Heroku ChatOps Slack app here Clicking that link will prompt you to grant the Heroku ChatOps app permission to access your Slack workspace: After that, you can add the Heroku ChatOps app to any Slack channel in your workspace. After adding the app, type /h login and hit Enter. This will prompt you to connect your Heroku and GitHub accounts. You’ll see several Heroku OAuth and GitHub OAuth screens where you confirm connecting these accounts. /h login (As a personal anecdote, I found that it took me several tries to connect my Heroku account and my GitHub account. It may be due to having several Slack workspaces to choose from, but I’m not sure.) (As a personal anecdote, I found that it took me several tries to connect my Heroku account and my GitHub account. It may be due to having several Slack workspaces to choose from, but I’m not sure.) After connecting your Heroku account and your GitHub account, you’re ready to start using Heroku in Slack. View All Pipelines To view all deployable pipelines, you can type /h pipelines : /h pipelines View Pipeline Info To see information about any given pipeline, type /h info <PIPELINE_NAME> . (Anything you see in angle brackets throughout this article should be replaced by an actual value. In this case, the value would be the name of a pipeline — for example, “heroku-flow-demo-pipeline”.) /h info <PIPELINE_NAME> View Past Releases To view a history of past releases for any given pipeline, type /h releases <PIPELINE_NAME> . /h releases <PIPELINE_NAME> This command defaults to showing you past releases for the production app, so if you want to see the past releases for the staging app, you can type /h releases <PIPELINE_NAME> in <STAGE_NAME> , where <STAGE_NAME> is “staging.” /h releases <PIPELINE_NAME> in <STAGE_NAME> <STAGE_NAME> Deploy to Staging Now that we know which pipelines are available, we can see information about any given pipeline along with when the code was last released for that pipeline. We’re ready to trigger a deployment. Most engineering organizations have a Slack channel (or channels) where they monitor deployments. Imagine being able to start a deployment right from that channel and monitor it as it goes out! That’s exactly what we’ll do next. To start a deployment to your staging environment, type /h deploy <PIPELINE_NAME> to <STAGE_NAME> , where <STAGE_NAME> is “staging.” /h deploy <PIPELINE_NAME> to <STAGE_NAME> <STAGE_NAME> After running that command, an initial message is posted to communicate that the app is being deployed. Shortly after, you’ll also see several more messages; this time, in a Slack thread on the original message: If you want to verify what you’re seeing in Slack, you can always check the Heroku pipeline in your Heroku dashboard. You’ll see the same information: The staging app has been deployed! Promote to Production Now, let’s promote our app to production. Without the Slack commands, we could navigate to our Heroku pipeline, click the “Promote to production” button, and then confirm that action in the modal dialog that appears. However, we’d prefer to stay in Slack. could To promote the app to production from Slack, type /h promote <PIPELINE_NAME> . /h promote <PIPELINE_NAME> Just like with the staging deployment, an initial Slack message will be sent, followed by several other messages as the production deployment goes out: And — voilà — the latest changes to the app are now in production! Conclusion Now, you can start and monitor Heroku app deployments all from Slack — no need to context switch or move between multiple apps. For more use cases and advanced setups, you can also check out the docs . check out the docs Happy deploying!

Heroku for ChatOps: How to Start and Monitor Deployments From Slack

Enhancing Application Stability and Security with Heroku Logplex

In the previous article in this series, we looked at how we could automate deploys to Heroku using Heroku Flow for our CI/CD. That setup had two Heroku apps for staging and production but only used a single main branch. The staging app was automatically deployed when you committed to the main branch, and the production app was manually deployed by clicking the “Promote to production” button in the Heroku pipeline. That strategy assumes that you’re doing “trunk-based development,” in which you commit to a single main branch in your code repo. However, some engineering teams still follow a branching strategy called Gitflow, which involves using a dev branch and a main branch. Feature branches are merged into the dev branch to deploy code to a staging environment and on a regular cadence, the dev branch is merged into the main branch to release the code to the production environment. In this article, we’ll consider how we can configure Heroku Flow to meet our CI/CD needs when following the Gitflow branching strategy. We’ll use our Heroku Pipeline to deploy our app to our staging environment when we push to the dev branch and deploy our app to our production environment when we push it to the main branch. Ready to go with the flow? Getting Started If you’d like to follow along throughout this tutorial, 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-gitflow-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’re going to create a Heroku pipeline that includes two apps: 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. Nice work! Creating Our Staging and Production Apps As we mentioned, we’ll use two environments for our app: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. The production environment is where code is 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 dev 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 dev branch is targeted, and check the box to “Wait for CI to pass before deploy.” In a later 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. Now let’s do the same thing for the production app, but this time choosing to deploy our production app whenever we commit code to the main branch. Enabling Heroku CI If we’re going to require CI to pass, we had 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 which get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to manually review your changes. 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 to 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 review apps to be automatically created for each PR.
The second box ensures that the review app isn’t created until CI passes.
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 from the dev branch to our staging app.
We enabled automatic deploys from the main branch to our production app.
We enabled Heroku CI to run tests for every PR.
We enabled the creation of Heroku review apps for every PR. Now, let’s see it all in action! Create a feature branch off of your dev branch with any code change you’d like, and then use that to create a PR in GitHub to merge that feature branch into dev. I made a very minor UI change, updating the heading text from “Heroku Flow Gitflow Demo” to “Heroku Flow Gitflow Branching”. 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 that another piece of info gets appended to your PR in GitHub. The review app is 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. 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 Heroku automatically deployed the staging app since new code was committed to the dev 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 in production. You can create another PR to merge the dev branch into the main branch, or you can do this from your terminal by checking out the main branch and then running git merge dev and git push. Once you’ve committed these changes to the main branch, look at your Heroku pipeline again, and you’ll see that the production app was automatically deployed. And with that, your changes are now in production for all your users to see. Way to go! Conclusion If you’ve followed along this far, give yourself a pat on the back. Walking through these steps, we’ve configured everything we need for an enterprise-ready CI/CD solution for a team using the Gitflow branching strategy and multiple environments. It doesn’t matter if you prefer trunk-based development or Gitflow as your branching strategy — Heroku Flow can support either. Now not only can you host your apps on Heroku, but you can set up all of your CI/CD infrastructure on Heroku’s platform as well. In the previous article in this series, we looked at how we could automate deploys to Heroku using Heroku Flow for our CI/CD . That setup had two Heroku apps for staging and production but only used a single main branch. The staging app was automatically deployed when you committed to the main branch, and the production app was manually deployed by clicking the “Promote to production” button in the Heroku pipeline. using Heroku Flow for our CI/CD main main That strategy assumes that you’re doing “ trunk-based development ,” in which you commit to a single main branch in your code repo. trunk-based development main However, some engineering teams still follow a branching strategy called Gitflow , which involves using a dev branch and a main branch. Feature branches are merged into the dev branch to deploy code to a staging environment and on a regular cadence, the dev branch is merged into the main branch to release the code to the production environment. Gitflow dev main dev dev main In this article, we’ll consider how we can configure Heroku Flow to meet our CI/CD needs when following the Gitflow branching strategy. We’ll use our Heroku Pipeline to deploy our app to our staging environment when we push to the dev branch and deploy our app to our production environment when we push it to the main branch. Heroku Flow dev main Ready to go with the flow? Getting Started If you’d like to follow along throughout this tutorial, 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-gitflow-demo
$ npm install
$ npm start $ cd heroku-flow-gitflow-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’re going to create a Heroku pipeline that includes two apps: 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. Nice work! Creating Our Staging and Production Apps As we mentioned, we’ll use two environments for our app: a staging environment and a production environment. The staging environment is where code is deployed for acceptance testing and any additional QA. The production environment is where code is 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 dev branch. To do this, click the dropdown button for the staging app and choose “Configure automatic deploys” from the menu. dev In the dialog that appears, make sure the dev branch is targeted, and check the box to “Wait for CI to pass before deploy.” In a later 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. dev Now let’s do the same thing for the production app, but this time choosing to deploy our production app whenever we commit code to the main branch. main Enabling Heroku CI If we’re going to require CI to pass, we had 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 which get deployed for every pull request (PR) created in GitHub. They’re incredibly helpful when you want your code reviewer to manually review your changes. 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 to 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 review apps to be automatically created for each PR. The second box ensures that the review app isn’t created until CI passes. 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 review apps to be automatically created for each PR. The second box ensures that the review app isn’t created until CI passes. 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 from the dev branch to our staging app. We enabled automatic deploys from the main branch to our production app. We enabled Heroku CI to run tests for every PR. We enabled the creation of Heroku review apps for every PR. We created a Heroku pipeline. We created a staging app and a production app for that pipeline. We enabled automatic deploys from the dev branch to our staging app. dev We enabled automatic deploys from the main branch to our production app. main We enabled Heroku CI to run tests for every PR. We enabled the creation of Heroku review apps for every PR. Now, let’s see it all in action! Create a feature branch off of your dev branch with any code change you’d like, and then use that to create a PR in GitHub to merge that feature branch into dev . I made a very minor UI change, updating the heading text from “Heroku Flow Gitflow Demo” to “Heroku Flow Gitflow Branching”. dev dev 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 that another piece of info gets appended to your PR in GitHub. The review app is 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. 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 Heroku automatically deployed the staging app since new code was committed to the dev branch. dev 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 in production. You can create another PR to merge the dev branch into the main branch, or you can do this from your terminal by checking out the main branch and then running git merge dev and git push . dev main main git merge dev git push Once you’ve committed these changes to the main branch, look at your Heroku pipeline again, and you’ll see that the production app was automatically deployed. main And with that, your changes are now in production for all your users to see. Way to go! Conclusion If you’ve followed along this far, give yourself a pat on the back. Walking through these steps, we’ve configured everything we need for an enterprise-ready CI/CD solution for a team using the Gitflow branching strategy and multiple environments. It doesn’t matter if you prefer trunk-based development or Gitflow as your branching strategy — Heroku Flow can support either. Now not only can you host your apps on Heroku, but you can set up all of your CI/CD infrastructure on Heroku’s platform as well.

Go With the CI/CD Flow: Using Heroku Flow With Gitflow Branching

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

Stories, News & Mentions about HEROKU

Heroku’s Stories on HackerNoon

Heroku's News & Mentions