---
title: 'Kubernetes 101: Deploying Your First Application!'
source: 'https://youtube.com/watch?v=XltFOyGanYE'
video_id: 'XltFOyGanYE'
date: 2026-06-17
duration_sec: 0
---

# Kubernetes 101: Deploying Your First Application!

> Source: [Kubernetes 101: Deploying Your First Application!](https://youtube.com/watch?v=XltFOyGanYE)

## Summary

This video provides a hands-on, step-by-step guide to deploying a simple Python FastAPI application on a Kubernetes cluster. The presenter covers the entire workflow from local development and containerization to pushing the image to a registry, creating a cluster, and exposing the application to the internet via an ingress controller.

### Key Points

- **Overview of the process** [0:00] — The video outlines the steps: create a Python app, containerize it, push to a registry, create a Kubernetes cluster, define Kubernetes resources (deployment, service, ingress), apply them, and set up DNS.
- **Creating a FastAPI application** [1:10] — The presenter creates a simple FastAPI app with a hello world endpoint, using a virtual environment and installing FastAPI and uvicorn.
- **Containerizing the application** [5:33] — A Dockerfile is created based on FastAPI's documentation, using a Python 3.9 base image, copying requirements and source code, and running uvicorn on port 80.
- **Building and testing the container locally** [8:50] — The Docker image is built and run locally with port forwarding to verify the application works inside the container.
- **Pushing the image to Docker Hub** [11:05] — The image is tagged with the Docker Hub repository name and pushed to a public registry.
- **Creating a Kubernetes cluster on Civo** [12:55] — A three-node cluster is created on Civo Cloud, with Traefik ingress controller and metrics server installed by default.
- **Defining Kubernetes resources** [14:44] — A deployment (with 3 replicas, resource requests/limits) and a service (internal load balancer on port 80) are defined in YAML files.
- **Applying resources and verifying pods** [21:50] — The configuration is applied to the cluster, pods are created, and port forwarding is used to test the application locally.
- **Adding environment variables** [25:40] — An environment variable is added to the deployment to demonstrate configuration management, and the app is re-deployed.
- **Setting up ingress for external access** [27:24] — An ingress resource is created to route traffic from a subdomain (kates.devopsdirective.com) to the service, and a DNS A record is added on Cloudflare.
- **Demonstrating load balancing** [32:00] — The application is updated to display the pod hostname, and after rebuilding and redeploying, refreshing the page shows traffic being load-balanced across pods.

### Conclusion

This end-to-end tutorial demonstrates the minimum steps required to get a custom application from a local system running on a Kubernetes cluster, including containerization, deployment, and external access via ingress.

## Transcript

hey team sid here and welcome to getting
started with kubernetes this is going to
be a quick guide that takes us through
the basics of getting some code running
on our system and then deploying it into
a kubernetes cluster we're going to keep
things pretty simple and on the screen
here kind of the basic steps i'm going
to create a simple application using
python i'll containerize it i'll push
that to a container registry
create a cluster define the kubernetes
resources associated with my application
apply those resources within the cluster
and then set up the necessary dns to
actually allow traffic to reach my
application this is a video within the
broader context of my kubernetes
platform playbook series so far we've
talked mostly with theory but i wanted
to get hands-on and just show you what
it takes to get an application running
in kubernetes we're going to do things
pretty quickly today we're not going to
do everything
in the state that they will eventually
be in in that in that platform that
we're, going, to be, building, but, i, just
wanted to run through from scratch
getting some of your code running in a
kubernetes cluster rather than taking
some existing
container and deploying it into
kubernetes i think it's more educational
to actually create that custom image
ourself even if it's quite simple today
i'm going to be using a python package
called fast api to create a super simple
api application that will then bundle up
the very first thing i'm going to do is
to create a python virtual environment
now this video is not about how to
manage your python dependencies and use
virtual environments so i'm just going
to do it this basic way
by saying python3
and the end
and i'll put that in the vn
directory
so this created a local directory called
vn and that's where it's going to
install my local packages i do need to
activate that virtual environment so i
can source the file
vn
bin
activate
and now we can see that my kubernetes
getting started virtual environment is
activated
there's a couple of packages that i'm
going to install so now i'm just going
to do pip install
fast api
we're also going to install
uvicorn that's the web server that we're
actually going to use
and so we now have those two packages
we can do pip freeze to see all the
sub packages that it may have
uh installed and so i'm just going to
create a requirements.txt file with two
things in it uh this fast api and the
the uvicorn package and hopefully i'm
pronouncing that right so i'll do code
requirements.txt
great
and the two things that i want in there
are fast api
and
unicorn
rather than pin all the way to the patch
version
i will do this
and that will allow it to automatically
upgrade
if it needs to
but only at the patch version level so
now if i do pip install
r requirements.txt
it should say that all the requirements
are already satisfied great
at this point i'm just going to go
through the
most basic application
intro here
example create it so we're going to
create a main.pi file i'm going to do so
within an app directory so i'll do make
dir
app cd app
we're going to
code
touch
init dot pi
and then we're going to open up a
main.pi
and this is going to be where our actual
application lives
and so i'm just going to paste in that
code from
the docs
i'm going to make it even simpler we're
just going to have the hello world for
now
and that means we don't need the
import from the typing package
there we go
we're going to actually run the server
with uvicorn so i'll just copy this
command and then run it here from within
that app directory
uh now it is running on port 8000 so if
we go
to our
browser and access localhost
8000
great we can see our application
i can change this to be something else
hello youtube
save it
uh it restarted our application and now
if i refresh the page we get the new
updated response from our api great
so that is the basic application that
we're going to use
in order to deploy to kubernetes we need
to take this and put it inside of a
container so kubernetes can run pretty
much any workload but the requirement is
that it only knows how to run containers
so rather than running this locally on a
virtual machine somewhere
we are instead going to bundle it up as
a container and deploy that container
image
as a container on kubernetes
so in order to do that there's actually
some good documentation in the fast api
page
here
about how to run fast api inside of a
container
good background here if you're not
familiar with containers i would read
that
but and if we get down to here we see
pretty much the same
code that we're using before
and then it gives us the sample docker
file so i'm going to create a docker
file
so i'll kill our server
great
at the top level i'm going to do
code docker file
and paste in
their sample code
and so if we just go through and look at
what this is doing it's taking a base
image so this is a publicly available
base image that i believe is debian
based running python 3.9
it's setting up a working directory so
this is where inside of the eventual
system that we're deploying it should
use as the working directory
we then copy in our requirements.txt
file so that's this file here
and the reason that we copy it in
first before we copy in the rest of our
source code as we build container images
the each individual step is cached and
so by copying this in
separately from our source code which we
copy in here
we can take advantage of that caching
such that we only have to
reinstall our dependencies if we change
one of those dependencies if we instead
copied in all of our code first and then
did pip install every single time we
changed our source code we would need to
modify or rerun this step when we built
the container image
okay uh we then
run a pip install and so it takes that
requirements.txt that we just copied in
uh installs those dependencies
we then copy in our source and so
because i place it in this app directory
it will get copied in at the
root slash code slash app a directory
inside the container and then finally we
specify the command that should be run
when we actually
issued this
when we run the container
in this case it's similar to the one we
had we had before
but now we're also specifying that we
wanted to run on port 80 instead of port
8080.
so i can do a docker
build and then i'll specify period to
say hey run docker build against the
docker file in my current working
directory
as we can see it's going through step by
step
and executing these commands
great so that container image is now
built one thing that we didn't do there
is tag it in any way and so i'm going to
rebuild it but i'm going to also add the
dash
t flag
here and i'm just going to call it for
now i'll change this tag in a bit
kate's fast api
we'll see that this time it's going to
build much quicker because we already
have all those layers cached so this
should only take a second
now we have that container image built
locally and we can run it locally as
well and so i can do a docker run
and then if we give it the name of that
container that i just tagged so kate's
fast api
but one thing i do want to do is port
forward from my local host 8000
to con the port 80 inside that container
so up here we're telling it to run on
port 80 inside the container in order
for me to be able to access the network
inside that container i need to connect
my macbook with the host of the
container itself and so by doing so with
this dash p flag i can now
run this
it's going to run my web server inside
of that container and now i can access
it like before on port 8000
so i refresh the page and we get the
same response
just to prove that it is indeed working
i'm going to switch this to
use an environment variable so i'm going
to say
import os
and then here let's just do
hello
and we'll do from
we'll make this an f string
from
and then rather than youtube
we'll put this
and i'll say os dot environ
dot get
and we'll look for the end flag and if
we don't find or we'll look for an
environment variable named end if we
don't find it we will return default
and
these will actually need to be single
quotes because we're inside of that
outer double quote
we'll rerun our
build command
then we'll rerun our run command
and now if we load here
we can see
we are
we didn't specify the environment
variable when we ran our container and
so it shows up as default m great
so the next step is to get that
container image into a registry where
we'll be able to use it from a
kubernetes cluster and so there's many
registries available docker hub is one
of the most popular
let me go ahead and get signed in here
i'm going to create a new repository for
this image
we'll call it
kate's getting
[Music]
started
create
and so now we're going to need to tag
this
with this
tag when we build the image
so i'm going to do build
so instead of kate's fast api
we now need to be this
and then for tag name for now i'll just
do 0.0.1
then
i can push that tag so it exists locally
but i need to get it to docker hub so
i'll do docker push
on that tag
it now is taking the container image
that i have built locally pushing it out
to docker hub so that we'll then be able
to use it because it's a public image
anyone could pull this and use it
and
if it was a private registry we would
have to do some additional work on the
kubernetes side to make sure we could
actually access that
now if we refresh over here we should
see that the image shows up with that
tag
awesome
and so we've
created a super simple hello world api
we bundled it up as a container image
we've pushed it to a registry and now we
can create a cluster to actually deploy
this into so one of my favorite places
to deploy a quick cluster is sibo cloud
it's a kubernetes focused cloud provider
i'm going to go ahead and log in
and one of the nice things about it is
that you can launch a cluster very
quickly it only takes a couple of
minutes and so i'll do kate's
getting
started
uh we're gonna spawn it with three nodes
sure
uh we'll create it with a
new firewall
we're gonna leave
access to the
kubernetes api on 6443 open you could
lock it down so that only my ip could
access it we also are going to enable
http traffic coming in and that's going
to allow me to access this
service, because, eventually, i'm, going to
set it up so that we can access it from
a public domain
for the sizes i'm just going to pick
these small nodes i'm not going to leave
this up for very long anyways
and that looks good
in terms of advanced options i'm just
going to leave it as the default this is
networking stuff
and then on the marketplace it does
install traffic which is a ingress
controller by default
as well as a metric server
and that's to enable accessing metrics
about things running in the cluster
we're going to end up using traffic as a
way to get traffic from the outside
world into our application
for now that's all i'm gonna do i'm
gonna click create cluster and it should
create here in a couple of minutes
in the meantime i can go ahead and
create the corresponding definitions for
how we want to deploy this into
kubernetes
and so i'm not going to go in detail
into
the reasoning behind kubernetes or what
it actually is i have some other videos
that talk about what kubernetes is
whether it's right for you whether you
should self-host or use a managed
clusters i'll link to some of those in
the description
but for the sake of this video i'm just
going to go ahead and define
the resources how we're going to deploy
them
and
and so i'll create a new directory
called kubernetes
we'll, go, in, there, and, so, we're, going to
have a few things i'm going to
do
we're going to run our code in what's
known as a deployment and so
at the lowest level in kubernetes you
deploy a pod
a pod is a collection of one or more
containers that are running together
and share
certain aspects of things including
networking so you can access each other
on localhost
however you you never want to create and
interact with pods directly there are
higher level constructs that allow you
to create what's called a deployment or
a stateful set and that deployment you
can specify whether you want one or more
replicas of a particular pod
configuration and then kubernetes will
look at that deployment create what's
known as a replica set and so replicaset
is kind of in between the deployment and
the pod it's a specific configuration of
that pod and then from that replica set
kubernetes will maintain however many
copies of the application that you want
and so in this case we're going to
create a deployment
and so i'll do code
and i'm going to start from the
kubernetes documentation on the
deployments page it's going to give us a
basic deployment here
i'll just paste this in
and then we're going to change a few
fields here so their sample is running
in nginx web server in our case we want
the
the image that we just tagged and pushed
to
docker hub so i'll copy this
uh we're going to use that image
this is going to be a fast api
fast
api we don't need to name it deployment
because that's what it is
we'll
say it's in the
fast api app
we will run
three replicas that's fine
we want this to match
there
the container port is port 80 that's
where we told fast api or uvicorn to run
inside our container
and this
is telling me that i don't have resource
limits so one
feature of kubernetes is you can tell it
how many resources a particular
pod or
a container within a pod should consume
and so
we can create a resources section
and then within that we can have
requests
and then for requests we can have
cpu
and let's say this takes 200
millicourse so one-fifth of a cpu uh
that's fine
and then for memory we can say let's say
it's going to take i don't know 300
megabytes
cool and then for limits
i'm not going to specify a cpu limit but
i will tell it
that we don't want the memory to go over
let's say 400 megabytes
okay that should be sufficient to run
our application we basically are telling
kubernetes hey we want to create a
deployment the deployment lives within
this api version so each type of
resource will have
an api version associated with it this
just happens to be the one that
deployment lives under we give our
deployment a name and then we also give
it labels and so these labels are going
to be useful later
when we want to route traffic to our
deployment we're going to need to be
able to use those labels to figure out
which pods we want to
assign or route that traffic to and then
within the deployment we specify here's
our our specification there are some
things that live at the deployment level
such as the number of replicas again we
can use this
this this selector field is what tells
the deployment how to figure out which
pods to manage
and so
that's why we have
this match labels here and then we have
that label applied within the template
itself
this template is a template for each pod
that the deployment is going to create
and so
we've got our label there
and then we have our specification for
the pod and so in the pod like i said
it's one or more containers in this case
we just have one we're naming that
container fast api we're specifying the
image that we pushed to docker hub we're
going to allow access on port 80 with
that reports field and then i specified
the resources that this container is
expected to and allowed to utilize
so that should be sufficient
we're also then going to need to specify
a service
and so a service is is basically like an
internal load balancer inside the
cluster in front of our deployment so if
we've got more than one pod we can have
a stable internal address to
use to address those pods
and it will load balance across the
multiple replicas and so i'm going to
create a service diameter
again i generally just go to the
official documentation
go here
here
it's relatively simple to
define a service
in this case
we will
go here
paste it in
i'm going to call it fast api once again
and then we're going to want our
selector to match the labels that we are
applying to our
deployment
and so in this case i'm going to change
this
to
selector app fast api
tcp is fine
and then we're going to use port 80 for
both the port and the target port so
incoming traffic on port 80 is going to
go to port 80 on those pods
and again that makes sense because that
is the port we're listening on and that
is the port within our container that
we're running our web server on
so we've got our deployment and our
service
um
it is likely that our cluster should be
done setting up by now it's been a
couple of minutes so i'll go back to
sivo
and we see the cluster is now running
i'm going to download my cube config
file so this is a
a config file with the credentials
necessary to access the cluster
like it is warning here this
file has essentially the admin config
and so you would want to protect this
very carefully and eventually you would
set up additional users within your
cluster with more limited permissions
such that not everyone needs admin
access so i'll download that cubeconfig
file
great
then i'm actually just going to put that
alongside my application
in an actual setting i wouldn't put my
admin credentials here in this folder
but for now that should be fine
i'm just going to call this cubeconfig
sivo cubeconfig
and then
you'll want to install cubectl which is
the command line for interacting with
kubernetes and specifically we need to
tell it how to find the
the
admin config that we just downloaded and
so in this case it is up a level or here
and you can set the cube
config
environment variable
and so i'm going to export that
and that is just going to be my present
working directory
and then
sivo cube config and so now when i do a
cube ctl
get nodes
it should show me the three nodes
running in my cluster so we see they've
been up for 11 minutes we're running
version 1.22.11
and that looks good
let's go ahead and apply our
configuration to the cluster so now i
have everything i need to do so i've got
my deployment i've got my service
and if i do
from that kubernetes directory
cubectl apply
dash f for file
give it the the local directory it'll
apply all the files within this
directory
and so we see it created both my
deployment and my service and now if i
do a cube ctl get pods
those three containers are creating it
was able to find those
in the remote cluster and so i'll do a w
for watch and it'll actually sit here
and update me anytime the status of one
of those containers changes
okay we've got one of our three running
the others should probably change soon
and now just to show you that they are
indeed running and doing the same thing
that we expected before
i'm going to go ahead and port forward
and i can port forward from my local
system to the kubernetes cluster so i
can do cube ctl
port
forward
and then we'll want to work forward
let's say to this specific pod
and i'm going to go from
8080
support 80.
and so this is saying from my local 8080
i'm now forwarding to 80 inside the pod
and so before we were on 8 000 now we're
on 80 80.
so 8000 is no longer running if i go to
8080
that request will be forwarded
into the cluster and we get back our
default environment
one thing we can do is specify an
environment here inside the pod
and so let's say
at this level
we can say
end
we'll have a
name
and this is going to be end
and then we're going to have a value and
our value is going to be sivo
now i can
re-apply my
definitions
that new deployment will be configured
if we then look at the pods we'll see
that the old ones are being deleted and
new ones are being created with that new
environment variable
we've got our new pods up and running
and so now if i port forward again
we'll be accessing one of those new pods
except i need to get the new name
and what we expect is when we refresh
this page now instead of default end
it'll show us from sivo awesome
and so this is kind of following best
practices of keeping your configuration
separate from your application so if
you're familiar with the 12 factor
manifesto
uh
from heroku that's a key component of
that is breaking out your configuration
from your application itself and so in
this way we're able to do things like
use environment variables there's what's
known as config maps and secrets within
kubernetes where you can define things
such as your credentials or additional
configuration that will modify how your
application actually runs
and so just showcasing how you can load
in configuration at runtime
here with this environment variable and
give a different behavior for your
application
and so the the final thing that we want
to do yes our code is running in the
cluster that's great but it's currently
not accessible to the world
right so we need to figure out a way to
get traffic from the public internet
into our cluster
and so
in order to do that we're going to use
what's called an ingress
and so there's an ingress type
controller
and that is going to allow
traffic
from the public internet
it's going to hit our cluster
it's going to get routed according to
the rules that we define
it's going to hit our service that we
defined and eventually end up on one of
our pods and so here
like i said when we're provisioning the
cluster we have traffic as our
ingress controller installed in the
cluster by default
and so if we look at the documentation
for it
and take a most basic
configuration
once again we'll do code ingress.yaml
uh they have this production namespace
we didn't use a namespace so everything
actually that we've deployed so far
is in the default namespace
and so
we can see there's the default namespace
there's cube system q public and cube
node lease generally you would want to
organize your applications into
different name spaces so that they can
be isolated from each other and
logically grouped
but in this case we just use the default
namespace
here we're not actually going to
have separate paths for separate
services we could do that and eventually
you would if you had multiple back-end
services you might have slash bar go to
one of them slash food go to the other
and so this ingress resource allows you
to have a single external load balancer
and route traffic based on different
paths that you specify
in this case though we're just going to
route the route path
and the back end is going to be the name
of our service that we use which was
fast
api
we're going to route on
port 80.
i'm going to set up a
subdomain of
let's say devops directive
um so in this case i'll do
kates.devops.directive.com
[Music]
and that should be sufficient i'm going
to name this fast api as well
and so i will do
once again the apply
we created our new ingress resource
the one thing we do need to figure out
though is the public ip address of our
cluster so that we can route traffic to
that
in order to get that public ip i'm going
to go here to the admin interface over
here
we see that we have this external
ip
right here
so now i'm actually going to go to
cloudflare where i have my
dns setup for devops directive
i will log in
yeah so if i go to uh devops directive
and then let's create an a record so
we'll go to dns
we will add a record
and this record will be for kate's
and then we'll paste in the ip address
save
and so now kates.devopsdirective.com
once that propagates we'll be going to
that location
and as you can see
we just accessed that and
it took us to our application so now we
have a public endpoint that's routing
traffic to the cluster that ingress is
routing traffic to our service which is
routing traffic to our pod where our
application code is running and so
that's kind of an end-to-end
example of how to get code from your
system and run it in the cluster one
neat thing we can do
is to actually
display
the
pod name here so that we can showcase it
load balancing across those
and so the way that i'm going to do that
is within my application here instead of
just
[Music]
using this i'm going to use
hostname and so hostname is what the pod
name is going to be inside that running
container
this means that i need to rebuild my
container image re-push it to docker hub
and then deploy with that new version
and so let's just go through that
workflow real quick
uh so if i do my docker build command
i'm gonna bump this to oo2
i was in the wrong directory so i'll
bump it to 002
great
now i'm going to push
the new image
and this type of thing where you're
building container images updating which
one is used in your deployment ideally
that stuff's going to live in a ci cd
system so that you're not doing this
manually because it can become really
easy to make a mistake but just for the
sake of demo purposes i'm going to just
modify this here our new image is in
docker hub
and so now i just need to
reapply this
configuration so i'll go into my
kubernetes directory
and then rerun my apply command
and then
if we do a cube ctl get pods we'll see
okay two of them have already cycled
this is the old one it'll be gone here
in a second
all of them are gone and should be
running our new version so if we can
actually look at the definition of
what's running here and say cube ctl get
pods
name of pod and then dash o yaml for the
output format yaml if we look at the
image field inside of our
container here
if we can find it
here is the image and we see that it has
version 002 applied this image pull
policy is another field we could have
defined on our
deployment and that would say when
should we pull the image from docker hub
it'll for each node that is running
it'll pull that container image if it's
not present if it is present it would
use that cached version so we need to be
careful
if we're using if not present if we're
if we're not
if we're modifying a tag in place with a
new code version it could it could cause
us to not get that new code version so
it's always best practice to
treat container image tags as immutable
and always increment when you're
deploying
into a
cluster
so
now if we refresh here that traffic
should be hitting the new version of our
application and should show us the name
of the pod looks like it didn't get
picked up and so why would that be
one thing we can do to debug
is let's actually go into the container
we can get an executable environment
inside the container
uh get pods
give ctl we can do exec and then dash i
t for an interactive tty session
we'll do name of pod and then we'll just
execute bash as the thing that we're
doing
and
the actual newer command is to put dash
dash here just so we don't get that
warning
and then let me do echo
host name
so that is what we wanted to show up and
so why
when we looked in our environment
did we not get that so if i do
let's just get a repel for python
so now we're in python we'll import os
os dot environment
uh i need to spell it right
ah because
okay so i was using sort of bash syntax
we actually just want to get the key
hostname
um
print
uh oh it is all caps
great uh and so removing that dollar
sign then we'll save once again we need
to
push a new version of our code
and so as you can see
this is the type of stuff you would want
to test locally test within your
continuous integration so you're not
having to iterate and push new container
images and deploy those into the cluster
in a future video i'll get into sort of
what a normal development workflow would
look like this is just meant to
demonstrate how to get code running from
your system in the cluster
but there's much more effective
developer workflows that don't require
this sort of slow
loop of rebuilding re-pushing the
container image every single time
but for now we'll do docker build we're
going to increment it to 03.
we're we're, gonna, push
we're gonna update our deployment
then we're gonna start once that has
finished cycling
uh we are almost there cool
now we would expect our hostname to show
up and so if we keep refreshing the page
here we see that the traffic
is actually getting routed to the
different pods
as shown by the the different post fixes
there
within our cluster and so
hopefully this has given you an idea of
like
the minimum set of things that are
required to get code from your local
system and deploy that onto
uh kubernetes and so just as a reminder
of sort of what we ended up doing
this is all in the context of this
series where i'm building out an
application platform i created a super
simple api application just kind of a
hello world using fast api with python i
took that wrapped it in a container
pushed that container to docker hub
i think created a cluster with sivo
cloud which enabled me to get a cluster
up and running that that cluster had
three virtual machines running in their
data center and so
kubernetes allows me to abstract those
virtual machines away and i can just
interact with them as a single cluster i
then took my application and put that
image that i built and pushed and put it
inside of the kubernetes-based resources
that i needed and so there i needed
three things i needed a deployment so
deployment tells kubernetes how to run
my container and what configuration and
how many replicas
a service which is the internal load
balancer that allows traffic to network
traffic to be routed across my different
pods and then thirdly the ingress
resource which tells
the ingress controller in this case
traffic which was installed in my
cluster by default if you're
provisioning a cluster elsewhere you
might have to install an ingress
controller yourself
but to tell it hey for traffic coming in
from
kates.devopsdirective.com
on the root path
route it to that service that we defined
earlier and so that allows that traffic
to come external public internet hit my
cluster ingress controller routes it to
the service service routes it to one of
those three pods and then we saw it load
balancing across as i refresh the page
the different pods were getting the
traffic
and so
that's all for today uh hopefully that
was helpful if you were just getting
started with kubernetes and sort of
confused about what the steps were for
getting your code from your local system
into the remote cluster like i said
we did things manually today a lot of
this is going to be automated to help
reduce the potential for human error
we'll also talk about improved developer
workflows i know this is a little bit
different style than much of my more
scripted content but hopefully you found
it helpful
if you enjoyed this and want to check
out other videos in the series there
will be links to the playlist in the
description and that's it for today and
remember just keep building
[Music]
thank you