►
Description
Spotify Backstage is an open platform for building developer portals. It provides a set of TypeScript libraries that can be composed together to build a developer portal for your engineering organization.
It was created inside Spotify and used there for a few years before being open-sourced in 2020. It is now a CNCF Incubating project. It combines a service catalog with a developer portal UI in order to improve engineering effectiveness and overall happiness.
Spotify Backstage can help you tackle a number of different engineering challenges.
- It collects software, tools, teams, people and other assets into one place where they can be easily searched and organized. This helps improve discoverability.
- It tracks teams and software assets, and making it easy to create a clear linkage between them.
- It makes it easy to define pre-approved templates and create new software from them. This speeds up the software development process and improves production reliability and homogeneity.
- It is the perfect place to detect when an engineering standard is not being upheld and it can nudge teams in a better direction.
The main features of Spotify Backstage include a software catalog, a framework for building plugins, a place to store technical documentation (TechDocs), Software templates and a scaffolder to run them and a Kubernetes plugin for providing visibility into how services operate there.
There are two main ways to get started with Spotify Backstage. You can self-host the open-source project, or you can use a SaaS provider such as Roadie.
A
A
A
A
Yes,
absolutely
but
see
the
audience
coming
up
so
is
my
advice
is
occur,
so
I
hope
this
fix
now.
Okay,
you
please
tell
me
if
the
voice
actually
fixed
right
now,
so
thank
you
very
much
joining
on
the
podcast
and
feel
free
to
mention
your
comments
regarding
the
backstage
open
source
project
because
we're
discussing
a
lot
about
it
today.
So
let
me
once
again
go
to
the
slide
and
give
a
small
introduction
of
where
we
actually
left
off.
A
So
we
are
talking
about
the
introduction
of
the
platform
engineering
and
how
this
backstage
open
source
project
help
you.
So
let
me
we're
starting
about
previously
like
what
the
need
for
the
developer
portal,
the
need
for
the
developer
portals
the
name
and
that
will
make
your
life
easier
and
when
building
the
platform
and
kubernetes
built
into
instructor
just
building
block
one
single
kubernetes
clusters
is
not
enough.
A
A
platform
is
a
collection
of
services
tools,
focus
on
enabling
team,
with
a
cell
surface
approach,
to
get
the
tools
that
they
need
and
when
they
need
them,
so
we're
actually
starting
about.
How
does
a
platform
look
like
and
we're
thinking
about
the
challenges
of
black
building
a
platform?
And
then
we
drive
the
conversation
forward?
A
How
actually
the
backstage
project
help
you
solve
this
problem,
so
mighty
negative
go
to
work,
go
to
once
again,
where
we
left
off
with
discussing
about
the
challenges
of
the
platform
building
the
platform
and
the
developer
story
like
what
the
things
developers
need
and
how
the
backstage
actually
open
source
project
solves
some
of
the
pain
problem
of
the
developer
story,
how
they
fit
into
this.
So
over
to
you
now
and
I,
just
I'm,
watching
the
chat
and
I
will
adding
question
as
I
see
in
the
chat.
B
B
B
So
what
backstage
decided
to
do
was
to
create
a
single
pane
of
glass
where
all
of
these
internal
tools
would
be
aggregated
and
whenever
one
created
the
new,
let's
say
a
new
deployment
tool,
a
new
visualization
for
deployment,
rollbacks
Etc.
Instead
of
creating
a
new
react
web
where
people
could
see
and
click
things,
it
was
easier
to
just
create
a
plugin
in
backstage,
make
a
new
visualization
very
fast.
B
You
already
had
a
website
to
deploy
that
to,
and
the
second
benefit
was
that
developer
teams
would
get
that
automatically
because
they
were
already
visiting
the
developer
portal
every
single
day.
So
adoption
was
easier
as
well.
It
was
faster
and
it
was
better
as
well
for
the
platform
teams,
because
they
would
develop
these
tools
much
faster.
A
Yes,
absolutely
absolutely
so,
if,
if
you
look
at
the
slide,
there's
a
developer
Story
coming
up,
let's
say
if
the
developer
is
actually
building
a
building,
some
kind
of
feature,
let's
say:
building
a
calculator
and
he's
as
infrastructure.
His
infrastructure
runs
on
top
of
kubernetes
and
we
have
a
platform.
And
now,
let's
a
developer,
can
I
have
a
new
environment
because
he
need
to
test
his
changes
before
the
they
come
into
the
production.
And
then
this
see
how
his?
How
is
this
new
feature
works
in
the
production?
A
So
basically,
what
happened
here
is
like
if,
if
you,
if
I
am
a
developer,
I
need
to
create
a
new
feature,
let's
say:
I'm,
building
a
calculator
and
basically
for
the
IDP
story.
What
does
is
you
don't
go
to
the
devops
team
to
create
a
new
environment
for
you,
you
don't
file
a
ticket
and
it's
asking
like
please
create
a
new
environment
for
me
where
I
can
test
changes
and
then
adjust
changes
it
so
testing
has
happened,
go
to
the
production
scenario,
so
IDP.
What
it
does
is,
give
you
the
platform
apis.
A
You
can
create
the
environment
for
yourself
and
then
you
have
a
there's,
a
key
reputation,
how
to
connect
with
the
cluster.
So
basically,
this
is
the
how
and
let's
say
in
future
he
wants
to
promote
his
changing
into
the
production
environment.
He
creates
some
kind
of
a
function
you
take
native
projects
or
other
cncf
projects
and,
let's
say
in
future,
he
come
up
with
the
app
V2
problem.
He
has
the
same
thing
like
he
create
another
environment.
A
He
created
testing
out
of
a
development
environment
created
and
there's
a
new
environment
created
for
them
and
that
you
can
see
the
changes
happening
when
you
go
to
the
production
environment,
he
want
to
move
with
this
code
and
feature
it
with
the
production
he
created,
an
Arco
CD
running
in
the
kubernetes
cluster
and
now
he's
can
merge
his
changes
and
all
the
things
is
actually
go
to
the
production
environment.
So,
let's
say
and
I
think
that's
is
where
the
backstage
come
into
the
play.
A
Let's
say
in
tomorrow
or
after
a
few
weeks
that
developer
need
a
flagger
in
their
cluster.
So
what
it
do
is
is
actually
install
a
cluster
on
the
kubernetes
and
install
a
flagger
on
top
of
it,
and
then
you
need
approval
from
his
team.
Lead
approval
from
the
devops
team.
Do
I
need
to
create,
install
this
Flagger
tool
or
not,
and
that's
where
the
pain
points
are
coming
up
like
you
would
there's
a
depth
of
skin
to
this
delivery
tool
already
exist
in
the
market.
A
Now
you
have
to
install
Flagger
flux
and
for
the
for,
for
this
IDP
story
is
how
it's
Chinese
like
now
IDP
you
just
create
a
platform
apis
and
now
the
flagger
and
the
flux
is
already
installed
on
the
cluster,
and
then
you
deploy
application
on
top
of
it.
It's
basically
a
payment,
give
you
some
kind
of
construct
that
is
already
available
in
the
cluster
and
you
as
a
devops
developer
engineer.
B
Apart
from
all
of
these
tools,
as
I
said
earlier,
one
is
to
catalog
everything
that
goes
to
production
and
all
the
other
environments
as
well,
so
that
one
could
see
everything
in
one
place.
The
catalog
is
doing.
That
is
the
inventory
of
all
the
services
libraries
websites,
users,
groups,
that
the
company
owns
and
also
know
well
for
each
service.
Who
is
the
owner?
Who
do
I?
Ask
if
something
seems
to
go
wrong
in
this
wrong
in
this
microservice
right?
B
B
B
So
those
are
the
main
few
things
now.
If
I
go
into
my
favorite
service
sample
service,
I
can
see
the
most
important
information
about
this
service.
I
can
trigger
a
pager
Duty
incident
and
I
will
page.
Whoever
is
on
call
for
this
service.
I
can
see,
who
is
contributing
based
on
GitHub
I
can
see
the
end
of
it
and
dependable
alerts.
Code
quality,
some
description.
What
is
this
service
doing?
The
main
links
to
let's
say
logs
graphs
alerts
Etc
the
latest
workflow
runs
in,
for
example,
GitHub
actions.
B
B
B
So
this
is
the
catalog.
This
is
the
entity
overview.
This
is
the
aggregation
of
all
the
third
party
services
or
internal
tools
that
have
important
information
about
my
service
and
makes
my
life
faster,
because
I
know
all
the
important
information
I
care
about
is
aggregated
into
one
place
and
I
always
know
where
to
go,
and
that
is
true
for
my
services,
the
ones
my
team
owns
and
also
any
other
service
in
the
company.
A
Yes,
that's
that's
very
useful,
so
a
quick
question
here
like
let's
say:
if
we're
working
on
this,
let's
say
sample
service
and
it
has
a
front-end
back-end,
it
might
have
some
cache.
It
might
have
some
database.
Let's
say
one
sample
service
is
comprised
of
front-end
back-end
cache
and
database
and
might
be
front-end
using,
let's
say
angularjs
and
the
back
end
we're
using
let's
say
node.js.
So
if
I
go
to
the
sample,
Services
I
can
see
how
my
service
is
comprising
of
and
I
mean.
B
Exactly
so,
it's
a
very
good
way
to
connect
all
the
services
together
and
it's
not
just
a
flat
inventory
of
everything.
You
can
also
create
graphs.
You
can
understand.
Okay,
this
is
the
sample
service
API,
who
are
the
consumers
in
this
case?
I?
Don't
have
any
sample
data
for
this,
but
all
of
these
services,
in
this
case
are
providing
the
same.
Api
and
I
can
see
which
ones
are
consuming
it
and
then
I
can
build
a
graph
of
all
of
the
systems
interconnected.
B
That's
a
very
good
use
case.
It
depends
on
the
plugin
that
you
install.
So
if
you
are
using,
let's
say
what
would
you
use
for
testing
the
coverage
and
uploading
the
coverage?
We
have,
for
example,
a
plugin
for
bug,
snug
and
things
like
that
on
trackbox,
but
if,
if
you
created
a
Plugin
or
install
a
plugin
that
is
already
existing
in
the
open
source
community
that
tracks
that
the
information
somewhere,
it
would
be
very
easy
to
just
display
it
here
as
one
of
these
cards.
A
Yes,
another
good
question
like
let's
say
if
your
service
is
hosted,
hosted
on
kubernetes
or
if
or
some
Australian
or
some
different
cluster
I
can
see.
One
thing
like
I
can
see
the
list
of
contributors
who
are
working
on
this
sample
service.
But
let's
say
if
that
service
has
some
devops
Engineers
that
actually
created
the
infrastructure
to
host
this
service
on.
So
all
this
information
is
still
available
in
the
catalog
or
it
is
hidden
in
some
other
places.
B
B
Kubernetes
clusters
as
well
of
course,
anything
that
you
you
can
imagine,
can
be
ingested
into
the
catalog
and
displayed
here.
Then,
once
you
have
the
backend
Service
as
well
like
a
sample
service,
you
can
declare
the
dependency
of
on
those
resources
and
with
that
you
can
display
later
the
graph
with
all
the
dependencies
between
Services
resources,
apis
and
so
on.
B
A
Well,
yes,
that's
a
good
news
because
I
actually
like
I,
don't
want
to
ruin
the
life
of
other
Engineers
by
installing
things
on
their
services
or
on
their
cluster
as
well,
so
actually
go
I!
Think
the
catalog
actually
give
us
so
another
I
think
so,
let's
say
if
I'm
using
the
front
end
and
the
back
end
was
aim
example
and
the
front
end
is
actually
using
on
the
angular.
So
if
I
go
to
the
angular
documentation
or
have
some
troubleshooting,
so
all
those
documentation
is
integrated
in
the
backstage.
B
Foreign,
so
ideally
one
would
see
okay,
what
is
the
website
that
is
having
issues?
Is
this
one?
You
will
go
to
the
catalog,
find
all
the
components
you
can
even
say:
I
only
want
to
have
websites
filter
the
one.
That
is
that
you
want
to
check
and
then
go
to
that
page
and
you
would
find
the
documentation
now.
I,
don't
think.
I
have
a
good
example
of
talks
for
websites.
So
let's
go
to
the
service,
my
favorite
service
again
and
let's
go
to
the
docs.
B
A
Yes,
absolutely
I
think
that's
really
really
interesting,
because
we
see
a
pain
like
if,
as
we
mentioned
like,
we
have
different
microservices
working
with
the
different
microservices
architecture.
Kubernetes
is
always
about
the
microservices,
and
the
new
paradigm
is
all
about
microservices,
so
one
I
have
one
microservices
comparises
comprises
of
three
four
different
micro
different
components
and
if
those
develop,
if,
if
all
the
documentation
you
can
place
in
the
same
place,
if
that's
really
an
ideal,
that's
a
heaven
for
the
developer
actually
to
go
into
one
place
and
check
all
the
documentation.
B
B
So
here
is
another
important
page
that
is
very
useful
for
let's
say
new
joiners
people
that
are
joining
a
new
team,
how
they
discover
what
services
they
should
care
about.
In
this
new
team,
you
can
have
someone
sitting
down
with
you
like
in
the
old
times
and
explaining
these
are
the
repos
I
care
about,
or
they
can
write
documentation
or
they
can
have
that
automatically
gathered
here
for
them.
So
it's
always
up
to
date.
A
So
basically,
one
question
here:
like
are
these
Associated
link
between
let's
say
I?
Have
a
micro
Services
front
end
and
it
has
three
four
repos
in
it
and
do
all
the
repos,
because
sometimes
teams
add
different
branching
like
Dev
testing
and
staging
or
production.
Sometimes
people
have
four
five
six
branches.
So
all
these
associated
with,
let's
say
I-
have
a
front-end
deployed
in
depth,
testing
and
production.
A
A
A
Basically,
it's
change
from
Team
to
team
organization
to
organization
and
companies
to
companies,
but
all
the
things
actually
exist
in
the
catalog.
It's
really
interesting
like
if
I
am
a
developer,
because
I
spend
a
lot
of
time
doing
the
develop
event.
I
want
to
be
focusing
on
one
stage.
We
can
see
all
the
things
happening
for
my
application
because,
let's
say
if
my
someone
from
my
team
is
working
on
the
back
end
I
not
go
to
the
another
dashboard
and
see
how
the
background
backhand
is
work.
I
can
see
in
the
One
dashboard.
A
The
back
end
is
working
by
Martina
and
his
has
his
backend
is
deployed
on
this.
Application
is
deprived,
an
AWS
who
is
actually
contributor
to
all
these
back
backends.
So
I
think
this
is
a
very
useful
information.
I
think
anybody
watching
or
listening
to
us
is
really
interesting
to
go
more,
learn
more
about
this
tool
as
well.
So
can
we
go
to
part
number
two?
We
could
talk
about
scaffolder.
B
B
So
what
is
the
scaffolder?
This
is
a
tool
that
was
built
for
scaffolding
repositories,
it's
basically
a
tool
that
can
take
a
template.
You
can
define
a
template
for
let's
say
this
is
what
a
new
microservice
would
look
like
in
my
organization.
It's
a
JavaScript
or
node.js
microservice,
and
it
always
has
this
file
structure
whenever
I
create
a
new
repo
with
a
new
microservice
of
this
type.
B
That
is
one
particular
case
greater
than
one
microservice,
but
one
can
imagine
that
if
we
have
a
tool
that
is
a
scaffolding,
new
repositories
or
pull
requests
inside
existing
repositories,
one
can
also
say:
okay,
I
have
a
repository
with
my
terraform
code,
with
all
the
infrastructure
for
my
team,
Department
Etc
whenever
I
create
a
new
microservice
that
needs
a
database.
I
can
just
scaffold
a
pull
request
in
this
repository.
It
will
add
the
necessary
terraform.
B
Another
case
that
would
be
more
simple
would
be
creating
a
documentation
template
all
the
websites
that
are
representing
documentation.
Let's
say
I
want
to
document
all
the
golden
paths
in
my
company,
I,
perhaps
want
to
have
all
of
them,
follow
the
same
standards
right.
So
it's
accurate,
a
template
that
can
be
very
easily
executed
and
and
created.
For
instance,
then
all
the
documentation
is
more
likely
to
follow
the
same
standards.
B
So
if
we
go
back
to
the
database
case
and
the
service
case,
if
instead
of
asking
people
whenever
they
need
to
create
a
new
microservice
to
start
from
scratch
to
do
a
tedious
copy
pasting
from
my
next
system
microservice,
we
say
if
you
type
these
things
in
this
form
and
just
run
it-
you
can
have
a
new
repo.
Your
service
will
have
some
basic
code
with
one
endpoint.
B
That
is
just
a
demo
endpoint,
and
it
will
also
be
connected
to
production,
because
it
has
also
created
a
pull
request
in
the
terraform
repository
to
expose
it
into
the
development
environment
or
the
production
environment
that
can
cut
the
time
to
production
from
weeks
to
just
a
few
minutes,
and
this
is
what
this
Governor
is
trying
to
do.
So,
if
you
want,
we
can
take
a
look
at
the
demo
and
we
can
see
it
in
action.
B
A
So
I
think,
basically
what
I'm
understanding
here
is
like,
let's
say:
if
your
application,
yes,
you
keep
it
running,
I
think
so.
I
think
what
I'm
actually
getting
here
is
like.
Let's
say
if
because
so,
let's
say,
if
my:
if
I
want
this
service
to
be
deployed
with
this
kind
of
a
back
end
and
we
come,
we
have
come
up
with
that
in
the
point
of
the
organization.
Whenever
we
have
a
service,
we
need,
let's
say
RDS
or
we
have
a
mySQL
database
for
that
service,
and
we
want
this
to
be
a
standardized.
B
B
Yeah,
so
this
is
the
output
of
the
scaffolding.
It
has
created
this
new
repository
called
artist
service.
It
has
created,
and
this
doesn't
have
any
service
code.
It
was
just
a
very
simple
example
for
the
scaffolder,
but
it
has
created
this
file,
which
is
I,
want
everyone
in
the
organization
to
run
a
few.
B
It
has
also
created
a
workflow
for
the
merging
action
has
created
our
business
with
a
that
is
empty,
but
it
contains
a
template.
So
I
know
that
everyone
will
mostly
follow
this
same
kind
of
Standards
describe
what
to
do
to
run
it
to
deploy
it
and
so
on,
and
it
also
creates
a
catalog
info.dml
file
which
I
I
haven't
talked
about
before.
But
this
is
the
core
thing
that
goes
into
backstage
the
backstage
catalog.
All
the
metadata
for
all
of
the
services
is
created
by
developers.
B
Some
of
it
can
be
discovered
automatically
automatically,
but
the
main
things
are
created
in
demo
files
and
they
are
supposed
to
be
kept
together
with
the
service.
So
when
we
do
a
scaffolder
template
for
a
new
service,
it's
a
good
practice
to
also
keep
the
cataloging
for
yaml
file
together,
and
this
way
means
people
will
not
have
to
write
this
demo
themselves
anymore.
Hopefully,
every
time
they
create
a
service,
they
will
run
a
scaffolder
template
and
that
would
create
a
demo
for
them.
A
We
have
a
containers
and
these
containers
come
from
the
Registries
like
Docker,
Hub,
Quay
or
some
other
registry.
But
let's
say
if
I
want
to
restrict
some
all
the
people
in
my
company
do
not
use
Docker
Hub,
but
you
use
QA
registry
so
and
nobody
able
to
pull
the
images
from
the
docker
up,
but
they
eventually
go
to
the
career
registry
and
they
pull
the
images
for
that.
A
We
need
a
policy
engine
like
let's
say
kyberno
and
open
policy
agents
and
that's
one
example
of
policy
engine
and
let's
say
we
create
a
services
and
we
get
a
kubernetes
yaml
file
and
we
want
every
time
we
have
create
a
this
service.
We
have
a
policy
engine
or
the
policy
has
code
or
already
back
into
that
yaml
file.
So
again,
scaffolder
do
these
kind
of
things
as
well.
Exactly.
B
So
you
would
create
a
template
so
that
it
creates
this
open.
Sorry,
this
pull
request
and
that
will
request
will
contain
some
files
and
one
of
those
files
will
refer
to
this
policies,
so
anything
that
is
githubs
related
much
is
very
well
with
the
scaffolder,
because
the
the
main
expertise
of
the
scaffolder
is
to
take
some
template,
apply
some
values,
create
pull
requests
and
or
new
repositories.
Also,
this
new
repositories
also
can
be
set
with
Branch
protection
by
default,
and
so
on.
B
That
makes
it
very
easy
for
everyone
to
follow
the
same
standards
or
policies,
and
so
on.
The
other
thing
that
the
scaffolder
can
do
as
well
is
called
http
endpoints.
So
if
something,
let's
say
there
was
a
policy
engine
that
was
not
defining
githubs,
one
could
also
have
at
the
bottom
of
the
template,
and
it's
still
the
request
to
the
third
party
service
and
stay
enabled
this
policy
for
this
service.
A
Yes,
absolutely
so
I
as
soon
as
we
merge
a
pull
request
in
GitHub,
there's
some
predefined
checks
already
in
place
in
backstage,
and
then
that's
basically
Define
your
company's
standards
and
that
basically,
some
yaml's
file
the
matter
that
associated
with
it.
So
every
time
you
merge
a
pull
request
in
GitHub,
some
checks
already
in
place
when
that's
Jack
scaffolder
can
do
some
policy
stuff,
some
terraform
stuff,
some
other
stuff
as
well,
because,
let's
say
some
companies
want,
we
do
not
want
to
create
a
virtual
machine
that
has
much
of
the
ramip
CPU
Ramen.
A
Give
you
a
lot
of
the
dollars
when
it's
actually
spun
up.
So
you
restrict
your
team
to
not
create
virtual
machine
that
are
cost
effective,
like
that
much
cost
associated
with
it
so
and
as
as
soon
as
somebody
create
a
merged
equal
pull
request
in
GitHub,
you
actually
get
some
kind
of
things
that
restrict
you
for
creating
massive
virtual
machines
that
are
another
way
of
thinking
about
it.
So
that's
good
news
because
everybody
want
those
policies
and
these
features
as
well.
B
Well,
remember:
the
scaffolder
will
run
once
and
then
it
will
stop
so
everything
that
has
to
be
checked
for
each
pull
request.
I
guess
it
would
have
to
be
implemented
as
one
of
the
GitHub
ticks,
for
example,
like
a
GitHub
app
that
would
install
a
webhook
and
then
it
would
take
the
pull
request
right.
But
what
you
can
do
with
the
scaffolder
is
to
have
that
GitHub
workflow
run
for
all
the
pull
requests.
A
Oh
yes,
I
get
it
so
basically
it's
create
the
pull
request
and
once
the
pull
request
it's
created,
you
can
Define
GitHub
actions
and
then
you
create
those
additional
requirement
for
your
organization
or
your
teams
or
your
devops
engineer
or
I
get
it.
So
basically,
the
scaffolder
is
actually
on
behalf
of
us
creating
a
pull
request
and
then
you
integrate
those
workflow
on
top
of
it.
I
get
it
good.
A
Yes,
I
got
it
I
got
it,
but
that's
really
makes
sense
to
me
because
I've
gone
through
those
situation,
it's
really
hard
at
it
before
that
as
well.
So
good,
so
I
share
the
link
once
again
for
this
video
recording
that
is
actually
Martina.
Sharing
on
this
on
a
screen
now
you'll
go
on
this
link
and
you
can
watch
how
scaffolder
Works
behind
the
scene
as
well.
So
another
question
before
we
go
to
another
subject
as
well:
is
some
companies
want
to
build
the
scaffolder?
A
B
B
So
once
the
template
is
created,
the
template
is
going
to
be
composed
of
two
things:
a
repository
with
a
folder
that
has
all
the
templated
files
and
it
would
take
all
of
those
files
and
create
the
templated
version
out
of
them
and
a
yaml
file.
That
is,
that
defines
what
the
template
needs
to
do
when
it
runs
once
you
have
that
you
can
register
the
template
in
backstage
in
the
catalog
as
if
any
other
entity
and
once
it's
registered
in
the
catalog,
and
actually
they
can
be
seen
in
the
catalog.
A
Yes,
absolutely
absolutely
or
if,
let's,
if
I,
if
I
connect
this
discussion
with
a
scaffolder,
so
all
these
template
can
be
used
as
a
scaffolder
or
scaffolder
is
basically
a
thing
that
you
create
and
create
a
pull
request
from
you.
And
then
you
create
another
additional
policy
but
I'm
thinking
like
if
scaffolder
as
a
library
or
some
kind
of
an
engine
that
people
can
generate
and
then
other
people
can
use
it.
A
Yes,
I
get
it
I,
get
it,
but
definitely
I
will
try
to
see
some
of
the
stuff
is
because
it's
a
really
cool
now,
because
I
I,
definitely
only
because
if,
if
somebody
created,
let's
say
the
scaffold
will
generate
a
pull
request,
it's
actually
create
a
very,
very
wonderful
workflow
for
the
development
team
as
well.
Then
you
create
some
kind
of
GitHub
actions
that
you
can
run
on.
The
pull
request
then
create
policy
engine
that
can
actually
test
the
data
form
file
and
then
can
actually
deploy
stuff
into
the
production.
A
A
B
The
idea
of
this
is
to
aggregate
all
the
technical
documentation
into
one
portal
if
all
the
technical
documentation
for
each
service
is
in
one
place,
and
it's
easy
to
add,
because
it's
in
the
same
repository
as
the
code,
it's
easy
to
keep
up
to
date
and
so
on.
The
BET
is
that
the
documentation
quality
over
over
time
will
improve.
B
It
will
be
more
accessible
to
everyone
in
the
company,
because
it's
very
open
anyone
can
search
for
the
artist
service
I
created
earlier
and
see
what
the
API
is,
what
the
documentation
for
the
service
is,
and
so
on.
It
speeds
up
onboarding
of
new
joiners
as
well
it
it
makes
it
easy
for
people
to
collaborate
across
teams.
B
A
Yes
and
I
think
might
be
the
question
the
people
mind
like
let's
say
if
you
integrate
the
technical
documentation
inside
the
backstage,
and
there
are
some
plugins
that
you
are
using,
let's
say
third-party
libraries
that
are
you're
using
they
have
their
own
website
and
their
documentation
live
in
their
own
website.
But
this
documentation
is
now
also
lives
in
the
backstage
as
well.
How
the
updates
work
for
both
of
the
places
like?
A
Is
it
updated
effectively
in
the
backstage
Plus
in
their
own
website,
or
do
actually,
you
are
actually
responsible
for
the
documentation
that
is
actually
necessary
for
you
not
for
the
third
party
Library
you
actually
creating
a
documentation
that
how
you
are
using
the
third
party-
libraries,
not
how
the
third
party
Library
Works
install
configure
or
how
they
are
using.
So
that
is
actually
the
question.
B
Documenting
something
else,
yes,
so
one
thing
the
main
case
here
is:
do
you
have
your
code?
The
code
is
service
right,
it's
classified
as
a
service
and
it's
in
the
catalog.
Then
that
code
also
has
Tech
talks
associated
in
the
same
repository,
but
one
can
also
create
a
repository
that
only
contains
technical
documentation
also
in
markdown,
and
then
you
can
register
as
that
as
a
as
a
docs
kind
of
page,
and
you
don't
have
to
take
care
of,
let's
say
rendering
it
every
time
you
merge
a
pull
request
or
deploying
it
anywhere.
B
The
other
good
thing
about
the
catalog,
if
One
is
using
documentation
outside
of
Backstage,
is
that
you
can
link
to
anything
that
is
relevant
to
the
service
so
either
in
the
readme
file.
This
could
be
a
link
to
my
conference
page,
my
notion
page,
my
Google
Docs,
or
here
in
the
links
I
can
say
documentation
and
just
have
a
link
to
the
proper
page.
That
means
everyone
that
wants
to
find
the
documentation
for
a
service,
regardless
of
where
it
lives.
They
can
find
it
very
easily.
A
Yes,
absolutely
absolutely
that's
make
totally
sense
for
me
because
otherwise
what's
happening
right
now
is
people
creating
a
GitHub
repository
and
then
a
living
documentation
is
actually
exists
in
the
GitHub
repository.
What
happened
here
is,
as
the
team
leaves,
as
the
team
member
lays
from
the
company.
There
are
some
outdated
information
and
nobody
actually
take
owns
the
responsibility
of
updating
those
dogs
into
the
GitHub
repository
that
the
code
is
actually
is
actually
up
to
date,
but
the
documentation
is
not
saying
up
to
where
but
happening
with
the
new
team
member
joins
your
team.
A
You
are
actually
doing
having
some
mistake
because
he
reading
the
documentation
that
this
command
is
actually
used
to
build
up
the
container,
but
he
sees
the
error
because
now
the
version
of
the
container
container
they're
using
is
actually
updated.
But
if
that
information
is
visible
here
that
everybody
can
say
like
now,
he
leaves
the
team.
Now
that
outdated
information
is
fascinated
because
living
is
all
alongside
the
keyword.
You
are
just
click
on
the
one
navigation
and
all
the
documentation
lives
in
there.
A
So
actually
I
think
that
is
a
hugely
powerful
feature
of
the
backstage
as
well,
because
we
don't
have
other
solution
that
gives
you
the
flexibility
of
writing
the
everything
that
your
application
comprises
of
in
one
place.
That
is
one
of
the
feature
I
really
like
about
this
stuff
is
because
this
is
literally
so
much
powerful
because
you
are
now
troublesh,
you
are
troubleshooting
less
because
you
are
documenting
everything
in
one
place.
B
Exactly
and
you
can
do
things
faster
if
you
are
troubleshooting
an
incident
and
you
have
to
remember
where,
where
the
logs,
where
or
where
the
graphs
or
where
the
documentation
is
and
even
for
other
teams
things,
then
you're
gonna
spend
perhaps
20
minutes
looking
for
the
right
place
for
that
documentation.
Instead,
you
spend
two
minutes,
because
you
know
exactly
where
to
go
to
find
it
wherever
it
is.
So
it's
about
making
developers
faster
the
end.
A
Yes,
absolutely
and
basically
like
it
I
think
for
if,
let's
say,
if
somebody
using
kubernetes
then
kubernetes
as
service
meshes,
that
has
gate
Ops
then
has
let's
say
there
are
some
if
somebody
using
a
plugins
in
kubernetes.
These
are
so
many
of
them
and
let's
say,
if
somebody
using
policy
in
general,
they
go
to
their
let's
say:
open
policy
agent
website
or
the
kai
Warner
website,
and
then
they
have
the
living
documentation
in
four
different
places.
A
That
is
once
again
the
same
question,
because
a
lot
of
the
troubleshooting
you
are
doing
for
your
application
is
because
of
the
lack
of
documentation
and
lack
of
the
communication
skills
you
have
within
your
team.
So
I
think
this
is
actually
changing
your
culture
of
the
company.
You
actually
working
a
lot
on
standardization
and
less
on
the
troubleshooting
before
that
we
get
what
we're
doing
with
strip
spends.
Eighty
percent
of
the
time
troubleshooting
in
20
of
the
time
in
the
standardization
I
think
that's
really
a
wonderful
feature.
A
B
B
Right
so
we've
seen
a
few
plugins,
the
inside
backface
or
inside
Rhodey.
There
are
a
lot
of
plugins
in
the
open
source
Community.
The
community
has
been
amazing
in
this.
There
are
plugins
for
very
like
a
lot
of
very
common
tools,
and
that
is
great,
but
what
happens
if
a
company
runs
deployments
and
they
want
to
expose
an
abstraction
on
top
of
Argo
CD
or
they
aren't
using
ergocd.
They
are
using
some
old
way
of
deploying
things,
but
they
still
want
to
expose
that
information
in
a
nice
way
to
all
the
feature
teams.
B
B
You
can
do
things
like
exposing
deployments
or
visualizing
the
environment,
which
is
a
case
that
is
not
very
well
supported
today
in
backstage
requesting
the
test
environments
we
were
talking
about
earlier
and
so
on,
and
because
we
are
exposing
again
a
new
piece
of
infrastructure,
a
new
abstraction
to
everyone
in
the
same
single
pane
of
glass.
That
means
that
your
the
adoption
of
your
tool
will
be
very
fast
and
it
will
reach
all
developers.
Faster
people
will
start
using
it.
Faster
people
will
know
how
to
find
it
and
so
on.
A
Yes,
so
basically
what
I
see
like?
Let's
say
there
are
some
code
specific
plugins
there
are
some
plug-in-
might
be
helpful
to
visualize
on
infrastructure.
So
let's
say:
if
you
create
a
some
plugin
that
can
be
visualized,
how
you're,
in
how
you
stood
up
your
infrastructure,
then
you
make
it
available
as
a
Marketplace
and
everybody
can
use
those
plugin
as
well.
So
what
that's?
B
B
B
So
Tech
insights
is
a
way
to
expose
information
and
knowledge
about
the
way
that
the
organization
is
working
and
the
services
are
performing
to
the
developers
to
the
owners
of
those
services,
and
the
BET
here
is
that,
by
exposing
more
knowledge
to
the
teams,
the
teams
will
want
to
improve
the
quality
of
those
services,
or
maybe
those
teams
have
been
wanting
to
improve
security
and
reliability
of
their
service,
their
services
for
a
long
time,
but
there
it's.
There
is
so
much
pressure
from
product
that
they
cannot
work
on
that.
B
Well,
this
is
a
way
to
say:
I
have
this
critical
service
running
in
production
and
it's
lagging
behind
in
security,
because
I
have
five
critical.
That's
a
lot
but
I
have
a
couple
of
critical
vulnerabilities
running
in
the
air.
I
have
to
fix
that,
so
one
could
Define
standards
and
one
can
say
these
are
going
to
be
my
reliability
standards
level,
one
two
three
and
four
level
one
is
you
need
to
have
at
least
something
set
up
in
data.
B
Some
slas
is
a
loss
and
so
on,
and
perhaps
in
the
level
two
to
make
sure
that
there
is
enough
instances
in
each
kubernetes
cluster
so
that
there
is
high
availability,
the
same
for
security.
You
can
Define
lower
standards
for
services
that
are
not
critical
and
for
the
services
that
are
very
critical
or
exposed
to
users
directly,
you
can
say
don't
have
to
have
absolutely
zero
medium
vulnerabilities
in
their
dependencies.
B
So
this
is
what
this
product
is
doing.
There
is
a
baseline
in
the
open
source
to
build
your
own
Tech
insights
and
you
you
would
be
able
to
expose
this
to
your
developers
and
we
also
have
in
Brody
version,
and
it's
our
first
proprietary
feature
where
we
do
most
of
this
work
automatically
for
for
the
customers.
A
Yes,
absolutely
absolutely
so
before
we're
going,
we
need
to
share
some
learning
resources
with
the
people.
So
here
are
some
learning
resources.
You
go
to
the
backstage.io
in
the
website
for
the
building,
an
open
platform
for
building
developer
portal,
and
you
can
see
what
the
developer
portal
means.
There's
a
docs
for
the
backstage
I
think
that's
really
shiny
one,
the
enough
information
to
know
how
to
get
started
with
the
projects.
It's,
a
Wonderful
blog
post-
is
also
available,
and
the
big
thing
is
that
you
can
join
the
Discord
community
of
the
backstage.
A
I
am
also
there
and
you
can
actually
ping
us.
We
can
have
more
conversation,
we
can
see
more
conversation
there
and
if
you
look
at
the
Gate
of
the
Stars
after
the
kubernetes,
Stars
I
think
it's
slowly
but
surely
getting
a
lot
of
the
star
in
the
GitHub
repository
and
the
reason
why
people
are
starting.
It
is
because
I
think
we
spoke
about
today
and
there's
a
managed
service
of
the
backstage.
A
You
can
spun
it
up
locally,
manage
everything
by
yourself,
but
there
are
some
teams
who
are
building
your
life
or
investing
time
to
make
your
life
easier
by
building
a
managed
solution
for
the
backstage.
I
o
and
that's
necessary
now,
because
backstage
is
has
so
many
things
and
you
need
a
huge
huge
team
who
can
actually
work
on
the
backstage
as
well,
because
it's
also
a
software
who
has
patches
releases
back,
fixes
everything
and
it's
going
to
be
a
challenging
when
this
projects
grow
with
plugins
and
all
these
kind
of
Sims.
A
The
managed
Solutions
might
be
a
better
option
if
you're
looking
forward
to
it.
Here's
a
roadie
website
and
you
can
go
to
their
Twitter,
handle
as
well
and
see
what
the
new
updates
is
coming
up
every
day
and
in
future,
because
in
this
Monday,
as
just
in
Monday
of
this
week
of
20th
of
February,
we
hosted
a
kubernetes,
Community,
Days,
Pakistan,
I,
hope
in
future.
We
can
see
more
backstage
talk
in
there
if
to
go
to
this
link.
You
can
see
some
of
the
introduction
to
Backstage
presentation
by
Brad,
McQuay
and
Courtney
Nickerson.
A
You
can
enjoy
those
as
well
and
if
you're
interested
in
seeing
more
talks,
please
subscribe
to
this
Channel
and
we
will
see
more
content
into
it.
So
before
I
we
go
Martina.
So
can
you
let
us
know,
are
you
going
to
the
cubecon
if
some
of
the
com
people
are
going
to
the
cubecon
from
your
team,
especially
from
the
Rowdy,
how
they
find
you.
B
A
Thanks
thanks
thanks
once
again
so
before
we
go.
Let
me
actually
recap
in
a
very
small
words
of
what
we
actually
covered
today.
Spotify
backstage
is
an
open
platform
for
building
developer
portal.
It
provides
set
of
typescript
libraries,
which
can
be
composed
together
to
build
a
developer
portal
for
your
engineering
organization.
It's
great.
It
was
created
inside
Spotify
and
it's
used
there
for
a
few
years
before
being
open
source
in
2020.
A
It's
now
a
cncf
incubating
projects
in
combines
the
service
catalog
with
the
developer,
reportal
UI,
in
order
to
improve
engineering
Effectiveness
and
our
overall
happiness.
So
basically
it's
a
provide
features
like
it's
Pro.
It's
collect
software
tools,
teams,
people
and
other
assets
into
one
place
where
they
can
can
be
easily
searched
and
organized.
This
helps
improve
discoverability
it
tracks
team
and
software
assets
and
make
it
easier
to
create
a
clear
linkage
between
them.
It
makes
it
easy
to
to
Define
pre-approved
template
and
create
a
new
software
for
them.
A
They
speed
up
the
software
development
processes
and
improves
production,
reliability
and
homogeneity,
and
it
is
a
perfect
place
to
detect
when
an
inch
engine
standard
is
not
being
upheld
and
it
can
nudge
team
in
a
better
Direction.
So
that
is
a
major
feature
of
the
backstage.
If
you
like
it,
there's
a
website
check
that
out,
go
to
the
Discord
Channel
and
start
the
discussion
there
and
if
you've
looked
for
the
manage
solution,
routed
out
higher
is
a
place
for
you
and
thank
you
very
much
for
tuning
in
to
this
Channel
and
enjoy
listening
to
us.
A
Thank
you.
Martina.
It's
been
a
pleasure
talking
to
you
hope
to
catch
you
up
again
in
the
future
as
well.
A
great
talk
learned
a
lot
about
backstage
and
you
remove
some
of
the
confusion
of
mine
about
backstage
as
well.
So
thank
you
very
much
for
your
time.
Stay
happy,
stay,
wonderful,
everyone!
We
will
meet
you
again
in
the
same
channel
again
in
the
might
be
next
week.
Bye,
bye,
thank.