podoman

Yep, we don't charge for seats at all. Just usage. In fact, we're likely going to be adding a lower tier so that individual developers can use the tool (at about $50/month). With the direction we're going with the product, we see ourselves having several "products" long term (error monitoring, session replay, logging, etc..) so there's a lot of value in making smaller teams happy w/ pricing, even as they grow.

And if you ever give us a try, definitely send feedback our way; we have a discord community up at https://highlight.io/community.

Highlight also has a private by default mode. Totally agree that this is the right way to do it. Also, congrats on the recent launch :)

Makes a lot of sense. We're going to try to take a bit of a different approach, but no doubt that a successful business (like sentry) can be built w/o the gitlab model!

In the past, for customers in healthcare and fintech, we've had to actually pass on signing more restrictive contracts (BAA's, etc..) due to the liability. For such a small company, it was hard to be comfortable with situations like that.

Since then, we've done a couple things that will hopefully open up more opportunities to work with these sorts of companies. First of all, we have a "privacy by default" mode that obfuscates all text by default (see https://www.highlight.io/docs/getting-started/client-sdk/rep...). And secondly, we're hoping that open sourcing the tool will help these companies control the data they're collecting so they don't run any risks, and long-term, these companies pay us a license of sorts.

Thank you sir!

Very cool. Didn’t know y’all were investing in that. Always been a fan of posthog.

Thanks. Yeah, we actually use rrweb under the hood and have met with a few of the core maintainers. We're proudly powered by that project.

Any web-based application could be a good fit! We also support a lot of the gnarly session-replay features that a lot of other vendor don't: namely canvas recording, shadow dom etc.. (see https://www.highlight.io/docs/general/product-features/sessi...).

In terms of audience, most of our customers are startups, and the users at those companies are often engineers or technical product people!

Having used the Posthog product (which is really good btw!), its an "analytics" tool, so their replay product is very good at mapping user funnels to sessions.

On the OpenReplay end, its seems we have feature parity for session replay, but they don't have support for error monitoring and therefore linking errors to corresponding sessions (as far as I can see).

Nonetheless, happy to see other oss tools in this space!

That's a good point; we should be clear about what will always be free. Right now, literally everything is free, but what we'd consider putting behind an enterprise tier that are top of mind are: - multi-tenancy - enterprise authentication features (sso, saml, etc..)

Re: the gitlab link you sent, we really like the transparency around not making a free feature paid, and the fact that all tests are OSS.

Overall, we'll work on something like this. Thanks for pointing it out!

savvycal has a way better scheduling UI for when you share to other people. I agree that savvycal > calendly. I pay for savvycal.

checkout https://loops.so

Super cool. Did you do any research on MSK vs other hosted Kafka alternatives? I just came across: https://upstash.com/blog/serverless-kafka-launch

Hey friends. My team just worked on a project to handle 10x more traffic on our backend for indexing. Figured I'd share the blog post with y'all if you're interested.

Highlight (https://highlight.run) | Remote Friendly | Full-time | Hiring Backend/Full-Stack Engineers and a Product Designer

At Highlight, we're building "The Control Center" for your app. We aggregate session replay, error monitoring, and performance metrics to help teams better understand usage on their web application. We're currently in private beta, but post product updates on twitter (https://twitter.com/highlightrun).

We're a team of ex YC, Google, and Microsoft alumni and we're very well funded. Job postings can be found at https://careers.highlight.run.

Feel free to email me (jay@highlight.run) to get in touch.

Highlight (https://highlight.run) | Seattle Based, Remote Friendly | Full-time | Backend or Full-Stack Engineer

At Highlight, we're building "The Control Center" for your app. We aggregate session replay, error monitoring, and performance metrics to help teams better understand usage on their web application. We're currently in private beta, but post product updates on twitter (https://twitter.com/highlightrun).

We're a team of ex YC, Google, and Microsoft alumni and we're very well funded.

Feel free to email me (jay@highlight.run) to get in touch.

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?

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.

True that! At Reploy, we spin up Reployments, not Deployments! :)

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!

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.

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

> 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.

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

Definitely understand where tommy is coming from. From a timeline perspective, we are "copying release", but better put: we're working on the same thing :).

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.

Agreed! Woot!

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

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.

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

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 ^^)