Deploying a Next.js application is straightforward with platforms like Vercel and Netlify. However, when you want full control over your deployment and opt for Docker, the available guidance is sparse. This blog post covers the challenges of creating a Docker image for a Next.js application, including the multi-stage build process, differences between local and production environments, and necessary tweaks for the entrypoint script.
Using a multi-stage build significantly reduces the final image size and ensures that only necessary files are included in production. The Dockerfile uses the following stages:
This stage installs system dependencies and prepares the base image:
FROM node:18-alpine AS base
RUN apk add --no-cache libc6-compat bash
WORKDIR /app
This stage installs dependencies while ensuring caching optimizations:
FROM base AS deps
COPY package.json package-lock.json* entrypoint.sh ./
RUN npm ci --ignore-scripts
Here, the application is built using the dependencies from the previous stage:
FROM base AS builder
WORKDIR /app
COPY --from=deps /app/node_modules ./node_modules
COPY . .
RUN npx prisma generate --schema=./prisma/schema.prisma
RUN NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY=$NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=$NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY npx next build --no-lint
This stage prepares the final image, ensuring a minimal and secure environment:
FROM base AS runner
WORKDIR /app
ENV NODE_ENV=production
RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs
COPY --from=builder /app/public ./public
RUN mkdir .next && chown nextjs:nodejs .next
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static
COPY --from=builder --chown=nextjs:nodejs /app/entrypoint.sh ./entrypoint.sh
RUN chmod +x ./entrypoint.sh
USER nextjs
EXPOSE 3000
ENV PORT=3000
ENTRYPOINT ["/app/entrypoint.sh"]
CMD ["node", "server.js"]
For local development, you can build and run the container with:
docker build -t nextjs-app .
docker run --env-file=.env -p 3000:3000 nextjs-app
This ensures that environment variables are correctly injected at runtime.
In production, the image should be pushed to a registry and deployed with an orchestration tool like Kubernetes or a simple Docker Compose setup:
version: '3'
services:
app:
image: your-registry/nextjs-app:latest
ports:
- "3000:3000"
environment:
DATABASE_URL: "your-database-url"
NODE_ENV: "production"
Next.js does not automatically replace NEXT_PUBLIC_ environment variables at runtime. To work around this, we modify the .next build output dynamically using entrypoint.sh:
#!/bin/bash
test -n "$NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY"
test -n "$NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY"
find /app/.next \( -type d -name .git -prune \) -o -type f -print0 | xargs -0 sed -i "s#CLERK_PUBLISHABLE_KEY#$NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY#g"
find /app/.next \( -type d -name .git -prune \) -o -type f -print0 | xargs -0 sed -i "s#STRIPE_PUBLISHABLE_KEY#$NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY#g"
exec "$@"
This ensures that all NEXT_PUBLIC_ variables are correctly populated when the container starts.
Creating a Docker image for a Next.js application involves several challenges, from efficient multi-stage builds to ensuring proper runtime environment variable handling. By following these steps, you can build and deploy a streamlined, secure, and production-ready Next.js container that functions seamlessly in both local and cloud environments.
]]>I was screen sharing with a colleague the other day and realized how far I’ve come with my CLI usage. I’d like to share with ya’ll the tips and tricks shared with me that helped me get to where I am now, plus some new ones I’ve picked up along the way 😉
These tools and techniques will reduce context switching and help you achieve your goal faster.
Note: These tools and tips will be Linux-y. For Windows, use WSL.
Context switching is bad. Stay on the CLI and get more work done.
Obviously, for ephemeral environments, you get what you get and it is often not worth it to configure.
But for your personal or work laptop? Definitely explore the non-default options
Here are my favorites for the big three Operating Systems.
terminal is fine for a quick and dirty job. But you should make time to explore iTerm2.
Highly configurable, pretty, and full featured.
Ye olde windows has come a long way since the days of CMD prompt.
The new Windows terminal is a full featured terminal with some eye popping features out of the box. It has tabs! It features Azure Cloud shell! Powershell! All the Shells!
And then when you add Windows Subsystem for Linux (WSL)? 😍
You must try this terminal!
Mac and Windows have been my jam for sometime now. But last I checked, konsole was still the ‘terminal du jour’.
Lots of features and fun to use.
asdfManage all your runtime versions with one tool!
Yes, we have apt for debian or yum for centos/RHEL, or brew for MacOS.
These are fine for long lived CLI applications. But what about languages and tools?
Have you ever been in a situation where you had multiple versions of go that you needed to switch between?
Fine, use gvm. But then you have another project you need to switch between multiple versions of node.
And then add ruby, then rust, then ad nauseam…
asdf is the tool and language version manager to use.
Check out the full list of plugins here
fzfIt’s an interactive Unix filter for command-line that can be used with any list; files, command history, processes, hostnames, bookmarks, git commits, etc.
This is a blazing fast filter. So what, right? WRONG!
When you have a lot of things to search through, like files, command history, commits, processes, etc, you don’t want to get kicked out of the zone by a slow tool.
This will help you stay in it and get your work done faster.
PRO TIP: Use fzf with back search (ctrl + r) for an unbeatable back search experience!
There are so many shells out there to try out. Just because your OS came with sh, doesn’t mean you have to stick with it!
Here are a handful, in no particular order
Not a shell! Sorry!
But oh-my-zsh takes the Z shell to the next level.
If you are on a Mac, you gotta try this out. (zsh is the default shell for mac) And if you aren’t on a mac, take zsh (and oh-my-zsh) out for a spin.
The friendly interactive shell!
A new type of shell
Like grep but faster.
ripgrep is written in Rust and is amazing at recursive search.
Checkout some of the tool comparisons here and see the speed difference.
JSON and YAML have become popular formats for storing, sending, and communicating large amounts of information. Most CLI tools output in JSON or YAML, or have options to do so. Both AWS and Azure CLI tools (aws and az) output to JSON by default and both support YAML.
jq and yq allow you to slice and dice that output, making it easy to get at the parts that are important to you.
jq has this to say about itself:
jq is like sed for JSON data - you can use it to slice and filter and map and transform structured data with the same ease that sed, awk, grep and friends let you play with text.
Keeping with the theme of “staying in it”, gh is github on the CLI.
Don’t switch between browser and CLI to create a PR. Create one directly from the CLI!
Review PRs from your CLI!
Check for issues!
Clone repos!
Make a fork!
Whatever you do, don’t waste time by opening your a web browser and going ‘clicky clicky’ with your mouse.
like tree but waaaay better
This is for visually representing directory structures in the CLI.
No more are the days of ls ... cd ... ls ... cd ... ls ... etc etc etc !
Simply run br and see a beautiful, compact, structure that is easy to navigate and use.
You hear about the mythical “one-liner”. A command that can perform a complex task in a single line. This would be impossible without the pipe!
Introducing… |
If you are wondering where that is on your keyboard, on a standard QWERTY keyboard, it is above the return key and shares the key with \. Created by holding down shift.
shift + \ == |
It chains commands together.
Let’s take jq as an example
This command will output a file with cat and “pipe” it to jq
$ cat some-file.json | jq '.'
{
"hello":"world"
}
the output of cat is fed as the input to jq
You can continue chaining in this fashion until you’ve achieved the desired result. example,
$ cat some-file.json | jq '.' | grep -n hello
2: "hello": "world"
and speaking of cat, ditch it for…
a cat clone with wings
bat is similar to cat in that it will show you the content of the file you ask it to. But unlike cat, it provides the following
Plus, it has integrations with some of the tools we listed here!
an alternative to
find
While find is, and will probably remain, the most powerful CLI search tool, it can’t hurt to have something that is a little more intuitive and user friendly. Check it out at the link above!
I hope you learned something cool from this post!
Go out there, try something new, and start learning how to take full advantage of the most powerful tool on your computer… the Command Line Interface!
]]>The Terraform Console provides a local environment to interrogate state and prove out methods to interact with that state during the plan and apply phases.
There are three phases to writing Terraform: development, plan, apply. The plan and apply phase are Terraform interacting with the state file, whether in a speculative or performative manner. The development phase, however, is entirely under our (developers) control. One of the frustrating issues with moving from the development to the plan phase is correcting errors with our own code or adjusting the interactions between previously declared cloud resources. The Terraform Console can help alleviate these issues!
Let’s check it out!
NOTE
Use the examples from here to get started fast!
In an empty directory (or a directory with no Terraform files), run the command
terraform console
That is it! You should see the console prompt show up after you type the previous command. The whole thing looks like
kephalos@dev:~/an-empty-directory$ terraform console
>
where > is the console prompt.
In real life, you’ll already have Terraform files where you want to use the console. Your Terraform should be well-formed. The console performs some validation before starting. Some errors will still allow the console to start but others will require you to correct them before proceeding
Once you have well-formed files, you need to init the providers. This downloads any providers defined so that you can start using them.
terraform init
Once that has finished, you can run
terraform console
Here is a video of how it should look. This example uses the code found in my example repo.
Now we can start using the console!
Like a beat cop on patrol, the console can interrogate the locals. The locals{} block, that is! 😅
Anyways, if you want to follow along, fork my example repo
NOTE
You can use the
ghcli to do this easily!gh repo fork matthewaerose/terraform-examples
Let’s change directory into the basic example and start our console. Once started, let’s see what the locals block has to offer.
Given a file that has the following content
# locals.tf
locals {
this_is_a_object = {
foo = "bar"
a_num = 78.9
a_bool = true
the_list = [1,2,3]
the_map = {
foo = "bar"
baz = "bat"
}
}
this_is_a_num = 123.987
this_is_a_string = "hello, world!"
this_is_interpolated = "${local.this_is_a_string} The number is ${local.this_is_a_num}"
}
we can ask the console for any of that content.
kephalos@dev:~/git/terraform-examples/0-basic-framework$ terraform console
> local.this-is-a-num
123.987
> local.this-is-a-string
"hello, world!"
> local.this-is-interpolated
"hello, world! The number is 123.987"
> local.this-is-a-object.foo
"bar"
> local.this-is-a-object["foo"]
"bar"
> exit
Notice how objects can use the dot operator or by index for keys
> local.this-is-a-object.foo
"bar"
> local.this-is-a-object["foo"]
"bar"
Here is a video of what that looks like.
Besides asking the locals who they are, you can do the following:
merge, concat, or any function found hereStay tuned for the next post on outputs and data blocks!
]]>