
Launch HN: Reploy (YC S20) – Instant fullstack staging environments for web apps - podoman
Hello Hacker News! We&#x27;re Jay and Himank from Reploy (<a href="https:&#x2F;&#x2F;getreploy.com" rel="nofollow">https:&#x2F;&#x2F;getreploy.com</a>). We&#x27;re building a platform that allows teams to easily configure full-stack staging environments or &quot;previews&quot; of their web app which are created on every open PR.<p>In the past, Himank and I spent time at several startups (~10-&gt;200 employees), where we were on customer-facing, product-oriented teams. We often found ourselves in positions where we wanted to share our environment with designer&#x2F;PM&#x2F;sales folks who didn&#x27;t necessarily have a dev environment setup, and ngrok didn&#x27;t cut it.  Further, even when trying to share our environment with fellow engineers, there was always a slow down when requiring that they git stash, git pull, etc..<p>The solution to these pain points was either:<p>1) Waiting for a full staging or production deployment, which in most cases, wasn&#x27;t really practical (from a cost and&#x2F;or time perspective).<p>2) Using a static site hosting solution (Vercel, Netlify, etc..) which didn&#x27;t allow us to preview full-stack changes.<p>At some of these companies, an infra team had tried to build something like this, however, the &quot;preview&quot; workflow was very different than the &quot;production&quot; workflow, so there were annoyances (slow builds, lack of concurrent env support, no populating staging data etc..) that made the tool hard to use. This is where Reploy comes in! Especially in the current remote landscape, being able to have as many staging environments as features is helping teams move faster by simplifying and streamlining the feature development flow.<p>We&#x27;ve put a lot of time into making this dead simple to set up. Just connect your repo, give us the commands that you run on your dev machine, and we&#x27;ll spit out a live environment on a managed link. All of this configuration can be described in the `reploy.yml` file, which is essentially a simpler version of docker-compose :). And if you already have a docker-compose file, we can use that as well :).<p>Take a look at a demo on our site! (<a href="https:&#x2F;&#x2F;getreploy.com" rel="nofollow">https:&#x2F;&#x2F;getreploy.com</a>).<p>How does it work you may ask? The short answer is k8s. We schedule these environments on Kubernetes, however, we hide this from end-users so that all that they&#x27;re interacting with is the Reploy configuration (just a series of commands to start up your web app). We&#x27;ve also curated a bunch of &quot;runtimes&quot;  which contain common framework dependencies (reactjs, node, rails, etc..) so that if you don&#x27;t want to worry about docker, you don&#x27;t have to :) . And for the hardcore folks out there, we also support custom images.<p>A few notable features that Reploy offers (specific to the aforementioned &quot;staging&quot; workflow):<p>1) Caching of specific directories (node_modules, .bundle, etc..) -&gt; faster builds<p>2) Restarts of past environments -&gt; Let&#x27;s you compare the state of different commits<p>3) Notifications! -&gt; We&#x27;ll notify your team when a new environment is ready or failed the build process via slack, email, etc..<p>4) A &quot;setup&quot; hook where your team can populate a database with staging data, or configure the host environment to your liking.<p>From a pricing angle, we&#x27;re looking to charge like most CI providers. That is, we&#x27;ll charge a base price per engineer&#x2F;user (~$30) and prorate any additional usage over a max number of concurrent environments. On that note, we&#x27;ve realized that pricing for Reploy is a very interesting problem, as the types of users that are creating environments (engineers, devops teams, etc..) are not necessarily the only users getting value out of the product (PMs, for example). If you have any thoughts here, we&#x27;d love to hear them in the comments!<p>Feel free to request access at <a href="https:&#x2F;&#x2F;getreploy.com" rel="nofollow">https:&#x2F;&#x2F;getreploy.com</a> if you&#x27;re interested in getting up and running; also happy to answer any questions at `jay [at] getreploy.com`.<p>Overall, very excited to be sharing this with HN, we&#x27;d love to hear your thoughts and keep the conversation going :).
======
giovannibonetti
Here comes the elephant in the room. Please take it kindly since I'm trying to
make constructive feedback.

In my company we have been using: \- Heroku Review Apps for the back-end -
built with Rails, each branch/app has a separated (tiny) database \- Vercel
(formerly Zeit) for the front-end, which is very fast and each commit
generates a separated app - which is great for comparing changes.

Important: both of these platforms allow you to run review apps for free (as
in free beer) for a small team.

With that context, what advantage is there on using Deploy instead of any of
these platforms?

~~~
Ozzie_osman
We use Heroku Review Apps as well. We are considering moving to AWS, and one
thing that was holding us up was that setting up review apps in AWS would
require some extra work (it's not impossible but definitely not as easy as
Review Apps). So I can definitely see how a tool like this can have value if
you're _not_ on Heroku.

~~~
podoman
Thanks for chiming in. We're also looking to offer more than Heroku does w/
their Review apps feature :). I actually learned that the Procfile was a semi-
standard on this thread, so maybe a move from Heroku isn't too difficult.

Also, happy to chat more if you're interested in the product, let me know!
(you have my email ^^)

------
raghava
I have seen this problem very closely across multiple firms and environments.

Just a few points that I would request you to dig further.

1\. Quick immutable envs aren't so much of a problem for B2C apps.
Particularly for B2B apps, it's not just the "run-build--pull-image--deploy--
start-svc--share-url" that's the real hard part. The real hard part for B2B
apps is the test data - the sane dataset which needs to be replicated as well,
per environment. Nobody wants to use a test/staging DB where changes are
uncontrolled. Bottomline - Immutability isn't just at the app layer, has to
cover the test data and stateful parts (datastores) too.

2\. What's the real value of it? One possible way to figure out hassle-to-
value ratio, is the ratio of number-of-commits to number-of-builds, and the
ratio of number-of-builds to any number-signifying-quality. If more builds (=>
more number of envs cropping up, and brought down, that is a high rate of env
churn) do not mean increased quality, then anyone choosing such a solution is
really just doing it for the sake of feeling self-important or sounding smart.

One really has to be keenly tuned for the real business value, while
validating fitment of such tools for the org/business.

Happy to discuss more. I have been designing/building tools like this, as a
day job for quite some time.

~~~
podoman
Hi! Very interesting points: addressed them below.

1\. For the most part, with Reploy, users either

a) Use a staging db

b) Seed their environments with fixtures or test data.

c) Do a db dump of a common db

Each of them have their own tradeoffs, which, from your knowledge of the
space, are probably not worth describing in depth. The most ideal situation
given your description is probably (c) because you can control what data is
being seeded into each environment and introduce test data that everyone's
staging env can then use.

2\. I agree, but the problem here is that "any number signifying quality"
isn't very easy to metricize. From our current users, Reploy is generally a no
brainer. i.e. they go through the flow of having to spin up so many staging
envs (or are annoyed by the lack thereof) that they use our product. In the
near future, however, from a marketing/sales perspective we do want to do work
to figure out who exactly is feeling the pain the most, as this is who we want
to target.

What's your background building these types of tools, if you don't mind me
asking? Definitely down to discuss more!

~~~
raghava
> 1\. (c)

Yup, that's the most sensible option but the fitment really depends on the
context.

> 2.

IMHO, more thought is definitely needed, in case you want to avoid expert
beginners subscribing and cancelling it after a couple of months/quarters

> What's your background building these types of tools, if you don't mind me
> asking? Definitely down to discuss more!

Have been designing and building dev/rel/ops/maint/mon/ALM tools for the last
13 years, in large firms, SMEs and startups

------
AlexITC
It's interesting to see this, a couple of months ago I was discussing this
idea with a co-worker, we agreed it would be very nice to have it, but costly
to build/maintain.

The conclusion I got was that, we could use deterministic urls (just you like
you specify `[https://{repo-id}-{commit}-{service}.reploy.io`](https://{repo-
id}-{commit}-{service}.reploy.io`)), which can get linked automatically on
every PR.

Every PR could trigger an environment to be created, dropping it after it's
unused for a given period of time, on every commit, you could get the
environment built automatically when you get an user visiting the specific
url. This way, you don't waste too many resources, I wasn't able to find how
similar is this to what's implemented on Reploy.

Something I'd love to see, is a way to get mobile apps built for these
specific environments, it's kind of simple for Android, but not so simple for
iOS, so that if I'm trying a specific environment, I can run tests directly
from the mobile apps prepared for it. Is there any plan to do this? or any
trick to get a similar workflow?

What I dislike is the price per seat, as I don't see a direct correlation
between the number of Github users vs the number of environments, for small
companies, it tends to increase the costs a lot, which has prevented me to
integrate great tools, I'd prefer something more related to the number of
active environments, so that you can choose the number that works for your
team.

In any case, looks promising, and of course, wish you success.

~~~
podoman
To your first points about the logic for spinning up these environments, we do
exactly that :). Right now, we spin down environment after some time period,
and GC everything when a PR is closed.

Re: mobile, we've considered serving React native apps on a URL, as there are
already containers that support the whole ecosystem, but haven't actually
considered android. If an android binary was generated, how would we serve it
to end users?

Regarding the price per seat, that's an interesting outlook. For the most
part, people haven't been worried about pricing, mainly because they're
hesitant about spinning up too many environments. If this seems interesting to
you all, we'd be happy to chat more about pricing (as we're still figuring
things out :)).

~~~
AlexITC
> To your first points about the logic for spinning up these environments, we
> do exactly that :). Right now, we spin down environment after some time
> period, and GC everything when a PR is closed.

What about specific commits after the PR is closed? The use case I see it's to
be able to easily test whether a previous commit has the same bug you are
hitting in production.

Then you could simulate `git bisect` on real environments.

> Re: mobile, we've considered serving React native apps on a URL, as there
> are already containers that support the whole ecosystem, but haven't
> actually considered android. If an android binary was generated, how would
> we serve it to end users?

The React Native containers idea is an interesting one, which I wasn't aware
of.

Related to native mobile apps, iOS/Android allow you to upload test versions,
so that you can install the specific for your environment, another way for
android could be to provide the APK file directly somewhere.

> Regarding the price per seat, that's an interesting outlook. For the most
> part, people haven't been worried about pricing

I believe it depends on how your customers are, there are companies having
decent budget for dev tools, but if you think about companies that are
bootstrapping without investors, the cash available is tight, and lot's of
tools to choose from.

I could see myself paying $30-$60 USD/month (you mentioned $30 per seat), but
that would limit it to myself, and another collaborator, It's unlikely I'm the
only one in this situation.

~~~
podoman
Right now, we support branch-level commits as well. That is, you can add a
specific branch that Reploy spins up environments on (in addition to open
PRs). For any branch or PR that reploy is handling, you can "restart" previous
commits to do comparisons.

The idea for supporting any commit on the whole repo is interesting (and
honestly, not hard to implement), definitely see the benefit there!

Re: mobile. Yeah, maybe we could push arbitrary assets to a bucket somewhere
so that you could serve an android build there. We're definitely focused on
the web aspect, but this is exciting wrt/ making Reploy more encompassing.

And re: pricing. Got it. If you don't mind sharing more about your team's
situation, we can probably figure something out (my email's in the post). The
reason we charge per seat is because its a reasonable proxy for how many
environments are being spun up, and frankly we're still learning how to
metricize. It'd be cool to see what your team's workflows look like.

~~~
AlexITC
Sounds reasonable, I'll keep an eye on Reploy for the future.

Thanks for answering.

------
rubiquity
My memory might not be serving me right, but are there 3-4 of these types of
companies in YC currently?

~~~
podoman
We know of another company in a previous batch that does have a similar
offering. This is definitely a growing space!

~~~
dacharyc
Actually, according to my count, there are 9 other companies in this space
that offer deploy environments as a service, in addition to 6 platforms that
also offer this functionality as part of the platform.

I've been watching this space closely, as my org is one of the competitors
([https://www.tugboat.qa/](https://www.tugboat.qa/)) that has been around for
a few years. We started out as an internal tool in a development agency in
2012, and released this service as a product in 2016.

It's interesting to see all the new offerings in this space in the past 12
months. There's definitely an education problem, so it's probably good for all
of us that so many new services are popping up that offer this functionality,
therefore drawing attention to the fact that it's even an option. But the
space is getting pretty saturated at this point, which makes it more difficult
for newcomers.

~~~
podoman
Yeah this is definitely interesting. We built this because there's so much
room for innovation. Sure, there are a few people that offer staging envs, but
just looking at the diversity on this thread, there's clearly not a single
player that's taken over the market.

And from a sales perspective, rarely do we hear of a company not being
interested because "we're already using x".

I see a bunch of opportunities to branch out from staging; makes the space
really exciting imo.

------
fiddleschticks
I've seen a few of these "we run docker compose for every PR" solutions - did
extensive research for our own company before building it internally using a
slack bot.

Could you discuss how you are different than other (often free) offerings?

\- [https://www.releaseapp.io/](https://www.releaseapp.io/)

\- [https://getdockup.com/](https://getdockup.com/)

\- [https://vercel.com/](https://vercel.com/)

\- [https://render.com/](https://render.com/)

\- [https://devcenter.heroku.com/articles/github-integration-
rev...](https://devcenter.heroku.com/articles/github-integration-review-apps)

\- [https://www.netlify.com/](https://www.netlify.com/)

\- rolling your own using AWS SDK + spot instances + slack chatbot (our
solution)

~~~
podoman
Hi there, for sure! I'll put these companies in buckets:

[https://render.com/](https://render.com/) These folks are a production
solution and have added support for review apps. All that happens is a new
deploy of the production app on every PR. There's no support for spinning up
arbitrary commits, caching, etc.. Further, its not free.

[https://vercel.com/](https://vercel.com/),
[https://www.netlify.com/](https://www.netlify.com/) Only supports frontend
(and maybe serverless?)

[https://www.releaseapp.io/](https://www.releaseapp.io/),
[https://getdockup.com/](https://getdockup.com/) These are both more direct
competitors. Dockup is no longer around I believe. Wrt/ release we have
different outlooks on pricing, as they charge a large initial fee. The product
itself is similar, however.

And lastly, Heroku was discussed in threads below, but the general idea is
that if you're already on Heroku, using review apps makes a lot of sense! With
that being said, they don't support the features I mentioned above such as,
restarting runs, comparing commits, caching, etc..

Let me know your thoughts, happy to keep the conversation going!

~~~
anurag
(Render founder)

* Render PR previews have built-in caching.

* Many of our customers use Preview Environments (currently in early access). For every PR, Render automatically spins up a complete testing environment including static sites, servers and databases that can be seeded with a hook. It's similar to Heroku's Review Apps, but a fraction of the cost.

* Render's Preview Environments are free for static sites and prorated by the second for servers and databases. Regarding pricing: we charge for actual usage (vs. a per-seat model) because previews (and consequently our own costs) rarely scale linearly with developer count.

More generally, it's great to see more activity in the space because it's a
validation of our own product strategy, and there is obviously room for
multiple players.

~~~
podoman
Sorry if my assumptions were incorrect in the above post; and likewise, big
fans of Render's offerings :) .

~~~
anurag
No worries and thanks! Reploy looks great. It's especially useful for teams on
AWS/GCP who want to run this in their own VPC. Per-seat pricing makes a lot of
sense for that model.

~~~
podoman
Thanks @anurag, we should get connected at some point, just shot you a message
:) .

------
fkjadoon94
How do you compare with LayerCI
([https://layerci.com/](https://layerci.com/))?

~~~
podoman
The end result is ~similar, but their configuration is a little more involved
and isn't as simple as "give us the commands in your dev environment".

That being said, it seems like they're focused on speed, as they support in
memory caching, and have double down on restarting previous commits quickly.

~~~
tsergiu
In my opinion the syntax of layerci is relatively simple as someone coming
from docker, and does basically boil down to "give us the commands you use to
deploy"

However they also have the advantage that they can run deployments on
arbitrary runtimes. It looks like reploy only works if my app fits in the
runtimes that were preconfigured by you. Because of that, I can run not just
my dev deployment, but something very close to my prod deployment as well
(we've had multiple bugs that only show up in prod due to our build process).

And finally, their aggressive docker-like layer caching allows very
substantial speedups in not only builds, but tests as well. The speedups are
typically in the triple digits compared to a reasonably well-optimized build.

I think the differences are major enough that I wouldn't exactly characterize
the end results as similar.

Full disclosure: I know the founder

~~~
podoman
Hi!

> In my opinion the syntax of layerci is relatively simple

That's awesome! They've definitely built a nice product for some use cases,
can't disagree with that.

> Reploy only works if my app fits in the runtimes that were preconfigured by
> you

Reploy actually supports any arbitrary runtime. Checkout our docs:
[https://docs.getreploy.com](https://docs.getreploy.com)

> their aggressive docker-like layer caching allows very substantial speedups
> in not only builds, but tests as well

Makes sense; Reploy actually won't run your tests (or any other CI-esque
things to that note). We're very much focused on only spinning up
environments!

Overall, there is definitely overlap here. I'd argue that if someone wants to
spin up a frontend, backend, db, etc., it makes a lot more sense to enumerate
your `services` rather than try and serve them all in a single runtime (I
think this is called a Layerfile?). I'm not sure how a use case like this
would work with Layer, but that would be my hesitance in trying to set things
up.

Layer seems like a great option for running long jobs to really take care of
that speed up.

------
dpix
Looks interesting but seems like it mainly fits with a docker style
deployment? Does this also work with serverless tech?

At my current company we have a CI/CD setup that also deploys a per-PR
environment - uses terraform and gitlab pipelines to manage everything
including our production deployments.

I'd use this for side projects to get things visible but not for a real
production app as I'd want the deployment system to be the same between PR
environments and production

~~~
podoman
Most of our users are using Reploy for the concept of "Preview Environments".
That is, being able to view the environment before a merge happens.

In fact, in many cases, it doesn't make sense to do a full production
deployment on every PR (either from a time or cost perspective).

I do, however, understand your hesitancy regarding having a different
deployment structure for these previews. The reality is that if you want fast
builds an experience that makes it easy to compare different commits, etc..
there is a tradeoff.

~~~
dpix
Yep! that is exactly what our system also does. QA sign off and automated
tests run against our preview env. We aren't pushing PRs to prod.

It's just hard to justify the validity of a preview env if the deployment is
different to that of prod, the deployment and infra is part of what you test
IMO.

    
    
       The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.
    
    

What makes you say there needs to be a tradeoff? If you can deploy these
preview environments so easily why can it not be the same for production too?

I actually think this is a great sounding product. I've pushed in almost every
company I've worked at in the past to have per PR environments but never
actually had it working for real until my current workplace and it is
fantastic. It's for sure made easier with the use of serverless and/or
container

~~~
podoman
Hello! I'm slightly confused here, but I do agree with your statements.

Are you implying that Reploy should also support production Deployments? If
that's the case, then yes! We're also thinking in that vain more long term. I
personally feel like existing solutions have their downsides, and there's a
lot of room for innovation in this space :).

Regarding the tradeoff, I'm mostly referring to existing large companies that
have lengthy deployment pipelines. For them, Reploy is a good solution to
"preview" changes before they go into production.

> It's just hard to justify the validity of a preview env if the deployment is
> different to that of prod

For the "preview" use case, it often makes sense. i.e. I just wanna make sure
that a button works or something. But I do agree that the
production/integration-testing similarity is missing here. This is where the
Reploy for production idea is strengthened.

Last point: For really big companies, there's no way that their prod
infrastructure would fit into a Preview environment. This is where Reploy
(only staging) proves itself being a valid product on its own.

Sorry if my thoughts are jumbled, but really appreciate the
interest/questions.

------
binaryblitz
Very interesting. I'm actually looking at building something like this
currently (for internal usage).

How does this work with things like databases, user login, etc?

~~~
podoman
These are actually things that our current customers have run into; our
solution is reasonably generic. I've touched at your points below.

re: databases, one option is pointing your Reploy environment to a common
database. The other is to actually spin up a database within Reploy, where you
seed data or a do a dump (pgdump, mongodump, etc..)

re: logins, we generate deterministic URLs (checkout
[https://docs.getreploy.com/docs/links-
discovery](https://docs.getreploy.com/docs/links-discovery)), so you can tell
your auth provider what the links will look like. (Can talk more about this if
you like).

------
strzibny
At my previous job, we made pr-merger[0] which is a little utility that allows
you to merge all possibly mergeable open pull requests in your GitHub
repository. Using this tool, we always build a full stack preview of our app
before merging things to master branch.

[0] [https://github.com/cloudaper/pr-merger](https://github.com/cloudaper/pr-
merger)

~~~
podoman
This is pretty neat! Does pr-merger handle the deployment itself? From reading
the docs, it seems like the tool merges a bunch of PRs into a single branch,
correct?

I'm curious what the whole workflow looks like.

------
baldajan
Just a tip: always have your domain start with the brand name. “Get___”
“try___” “by___” etc are terrible because when a user is searching to quickly
go to your domain, they’ll type your brand name first (as that’s what will
come to mind).

In this case “r”, but your site won’t be listed as a quick suggestion cause
the domain starts with “g”.

I’d suggest “reployapp” or “reployenv” or something where brand followed by a
word/descriptor.

~~~
capableweb
Seems you're using Chrome, which autocomplete in the URL bar really sucks
(probably on purpose)

Try Firefox and have fulltext search available for you, will make your life a
lot easier. Firefox also don't have any incentives to send you to a search
result page and much rather find you the correct website directly.

~~~
baldajan
Majority of people use Chrome. So it’s a very valid tip regardless of what
browser I use.

------
latortuga
Cool idea and the video is a great overview of how it works so kudos on a job
well done there!

I'm sure this will come as not surprise, but this makes me think immediately
of Heroku Review Apps. Could you address directly why reploy is a better
service than Heroku Review Apps, especially for teams that are already using
Heroku?

Edit: I see Heroku Review Apps are addressed elsewhere in this thread, feel
free to ignore!

~~~
podoman
Hi there, yes this was discussed in a couple threads! Happy to answer any
other questions you have :) .

------
sz4kerto
We have something like this internally. It is useful in general, but not cheap
for large systems - even large k8s clusters can get full if you have dozens of
PRs open.

Useful feature suggestions for the future that already work at us: \- remote
debugging \- database snapshots \- environment cloning \- actual full k8s
support: larger stacks are already deployed on k8s, writing a compose file for
them is a pain.

~~~
podoman
Ahh yes. We've spoken to some companies that have existing helm charts that
they'd like to use with Reploy. Is this what you're referring to?

Regarding pricing, this is a good reason to use Reploy! Because all of the
scheduling is happening behind the scenes, we have the flexibility to offer
teams a more predictable pricing model.

------
wolco
Struggling to understand what languages/environments you support.

I saw node.js in a build file in the docs but no other information.

Who is this for? What can I support?

~~~
podoman
Sorry for the delay here. A list of runtimes is at the bottom of this doc
([https://docs.getreploy.com/docs/fields](https://docs.getreploy.com/docs/fields)),
but notably, we support arbitrary docker images.

That is, if you specify `image: node`, we'll pull from the public node image
on docker hub:
[https://hub.docker.com/_/node/](https://hub.docker.com/_/node/)

------
tylerjdurden
Great stuff! I'd love to use something like this at work.

Speaking of which, I work at a larger tech company, and the webapp we work on
is quite large. How does/would Reploy handle a webapp that doesn't have a
simple backend? i.e. the backend is distributed among many servers

~~~
podoman
Ah, good question! We've spent some time at larger tech companies, and
realized that when you have many distributed teams, you can actually run
Reploy with smaller subsets of your stack, and treat external dependencies
like you would for external providers.

For example, maybe your team contributes to a frontend/backend regularly;
you'd just staticly point the Reploy environment to other service dependencies
that don't change as often.

That being said, market-wise we're targeting <200 eng companies, but
definitely a cool thing to think about.

------
dom_hutton
I've implemented this same system in two companies throughout my career so
far. Take that as some validation.

How do you plan to handle the data layer?

~~~
podoman
Hi there! That's awesome, would love to keep the conversation going :)

I touched on this in another thread slightly, but the short answer is that we
support a 'setup' directive where the user can populate data into the
environment.

Most of our current users have a common "reploy" db that they dump into the
environment on each new run. And an even simpler approach is just pointing all
of your environments at a single db.

Any thoughts there? What have your experiences been like?

------
raiyu
You should double check your link to your Twitter account on your homepage as
twitter says the account is suspended.

~~~
podoman
Working on a fix; thanks for the heads up!

------
vidar
Quite similar to render.com or ?

~~~
truesy
Similar to [https://vercel.com/docs/v2/git-integrations/vercel-for-
githu...](https://vercel.com/docs/v2/git-integrations/vercel-for-github) as
well

I did a similar project that I pitched to a few VCs, got negative feedback,
then saw Vercel (was Zeit at the time) launch that feature. So I archived the
project & OS'd it. Guess I should have pressed on

~~~
podoman
I think this might also have to do with timing. As in, this "per-PR" iteration
model is now becoming popular. In our minds, after CI/CD, the next thing to
automate are ~full deployments.

------
mkchoi212
Cool stuff! Would be cool to see Reploy adopt formats other than web apps ;)

~~~
him229
Thanks for the feedback here! We recently started looking into mobile apps
through the lens of react-native-web but that's still not a priority on our
roadmap yet.

Was there another specific format you had in mind?

------
corobo
I reckon you could get a few more bumper stickers on that homepage

------
extrememacaroni
So we finally find out what a reployer does.

------
phoenix24
\- does reployer utilize a custom k8s operator? \- or does it generate
deployment + service yaml's from the reployer.yaml ?

~~~
podoman
At the moment, we're generating manifests via the kubernetes API. This may
change though! Take a look: [https://github.com/kubernetes/client-
go](https://github.com/kubernetes/client-go)

------
zorna
Very Nice!

