Hi hn, I'm excited to share https://codepreview.io with al of you, a project we have been working on since last year. After getting a few customers providing very nice comments, I finally feel brave enough to share this to the public.
CodePreview's main goal is to provide preview environments to web applications that haven't got into the K8s/containers path. In our Software Develipment company, we mainly work with small to mid-size businesses where K8s/containers are rare.
Becoming a unicor is not our goal, instead, we aim to get enough revenue to fund a team to maintain and keep improving the project. This is why we don't have any investors, we funded CodePreview's developemt through the revenue generated from our Software Development company.
There are many competitors that offer preview environments for K8s/Containerized projects, some of them even offer help to migrate to K8s/Containers, we are different in this sense because we adapt to the project instead of asking the project to adapt to us.
While we are still in an early stage, CodePreview has been usable for several months with no critical bugs reported, on the contrary, CodePreview has proven to be very useful for these cases with our customers:
1. A company where CodePreview exposes only the backend-api, allowing the frontend team to get experimental features integrated even though the frontend team does not have access to the backend code, normally, the company would have required to provide a brand-new environment which will be maintained by them, CodePreview has been working great for this use case.
2. Another company used CodePreview for a early stage project where founders are frequently running experiments, CodePreview has allowed them to compare multiple versions at the same time even though they don't have anyone managing the infrastructure, it's just CodePreview.
I'd be thrilled to answer any questions.
BONUS: https://codepreview.io has a button for hn users where you can join a room to discuss this project live (no-login required), I intend to leave this for a few hours.
Thanks!
EDIT: I set my title as "Launch HN" but it was automatically changed to "Show HN", I guess this is an hn restriction.
This is an interesting question, the codepreview integration can operate without a backend, in fact, some existing integrations work this way.
Still, a backend helps to:
1. Distribute the necessary settings/scripts to create a preview, this is now handled by a plain-old (password-protected) file server.
2. Allow users to manage their projects, for example, set variables/secrets, configure a custom domain, etc.
> how is it different from other companies
The main difference is that we did not go to the K8s way, which help us to easily integrate projects without asking our customers to adapt their project to us.
Besides that, there are no bots behind our contact pages, so far, we have a very close relationship with our customers.
> like Retool, Zeet, etc.
I wasn't aware about these tools, still, they seem to be tools for creating applications while codepreview allows generating previews for existing applications.
We can certainly compare these apps because there is some overlap, for example:
1. Netlify/Vercel handle production deployments while codepreview does not.
2. Netlify/Vercel have many more features than codepreview, still, codepreview is more flexible in what it can, do you want to pre-create users for each preview? no problem, do you SQS queues? you can get those, etc.
3. Vercel/Netlify are mostly about frontend previews (tied to js) while codepreview handles fullstack previews, in our demo, we showcase a web app preview built with Scala/Scala.js/Postgres, other stacks are supported too (like Java-based ones).
4. Vercel/Netlify charge per user while codepreview charges a fixed fee for all your users.
> Unlike most Docker environments, CodePreview usually builds in 5-10 minutes.
Uhh... that's really slow. What is CodePreview doing to make it take that long? You could spin up a VM and copy a binary over to it much faster than that.
I'd love to see more tooling in this space (most people don't need Docker!) but I didn't get a sense of what CodePreview is actually doing from the homepage.
> Uhh... that's really slow. What is CodePreview doing to make it take that long?
Building everything from source can take a while for some projects, for example, Scala/Rust. In our case, most of the projects we have integrated depend on Scala.
Other than that, CodePreview also provisions dependencies (databases, etc), generates SSL certificates + some other steps.
I have personally done some experiments to reduce these times and getting these down to less than 3 minutes seems doable, I have drafted a blog post explaining this. For simpler projects, it's easy to get the execution time to 1 minute.
> You could spin up a VM and copy a binary over to it much faster than that.
Copying the binary is one of the fastest steps.
There are projects take take less time,
> I'd love to see more tooling in this space (most people don't need Docker!) but I didn't get a sense of what CodePreview is actually doing from the homepage.
Is there anything more specific you can share? This is the 3rd time we work on polishing the landing page to make our purpose clear, it seems we are not there yet.
In short, Codepreview reacts to commits on Pull Requests, executing a pipeline that builds and deploys a temporal app version (using a new sub-domain specific to each PR), this way, you can preview the how the app looks like and how it behaves without pulling the code yourself, it has turned out to be very helpful for demos.
> Building everything from source can take a while for some projects, for example, Scala/Rust.
Gotcha, true. I think you're doing yourself a disservice by including compile times (mostly out of your control) in your answer to "How long does each preview environment take to deploy?"
> Is there anything more specific you can share?
I would like to hear some technical details about the environment that each temporal app version gets deployed to. Like, is it a normal VM I can remote into? Docker containers? Something fancy like Firecracker micro-VMs?
You might not want to make all of those details public, but I need a bit more of an understanding of how a product works to consider using it.
> Gotcha, true. I think you're doing yourself a disservice by including compile times (mostly out of your control) in your answer to "How long does each preview environment take to deploy?"
This is a very good point I haven't considered, I just updated the FAQ.
> I would like to hear some technical details about the environment that each temporal app version gets deployed to. Like, is it a normal VM I can remote into? Docker containers? Something fancy like Firecracker micro-VMs?
> You might not want to make all of those details public, but I need a bit more of an understanding of how a product works to consider using it.
I believe the landing page isn't the right place to share these, I'm working on adding a blog where these details would be explained.
To summarize, every customer gets its own powerful VM where all previews will run, previously, ssh-ing into the VM is doable but it hasn't been required since we started exporting the application logs.
Each preview is being executed as a systemd service with nginx in front to handle TLS.
If you are interested to know any particular detail, feel free to ask.
Yeah unfortunately I think the selling point must be misrepresented. You could build and deploy a container image from scratch on Fly.io in under a minute, and I don't even think that's an exaggeration. I rigged a simple branch preview thing that used Gitlab CI and Helm+Kubernetes a few years ago and I still don't think it took more than 5 minutes to build and deploy. (We were just using cert manager, ingress nginx, and other somewhat standard tools, nothing special other than the container registry and parameters passed to helm.)
18 comments
[ 2.7 ms ] story [ 54.6 ms ] threadHi hn, I'm excited to share https://codepreview.io with al of you, a project we have been working on since last year. After getting a few customers providing very nice comments, I finally feel brave enough to share this to the public.
CodePreview's main goal is to provide preview environments to web applications that haven't got into the K8s/containers path. In our Software Develipment company, we mainly work with small to mid-size businesses where K8s/containers are rare.
Becoming a unicor is not our goal, instead, we aim to get enough revenue to fund a team to maintain and keep improving the project. This is why we don't have any investors, we funded CodePreview's developemt through the revenue generated from our Software Development company.
There are many competitors that offer preview environments for K8s/Containerized projects, some of them even offer help to migrate to K8s/Containers, we are different in this sense because we adapt to the project instead of asking the project to adapt to us.
While we are still in an early stage, CodePreview has been usable for several months with no critical bugs reported, on the contrary, CodePreview has proven to be very useful for these cases with our customers:
1. A company where CodePreview exposes only the backend-api, allowing the frontend team to get experimental features integrated even though the frontend team does not have access to the backend code, normally, the company would have required to provide a brand-new environment which will be maintained by them, CodePreview has been working great for this use case.
2. Another company used CodePreview for a early stage project where founders are frequently running experiments, CodePreview has allowed them to compare multiple versions at the same time even though they don't have anyone managing the infrastructure, it's just CodePreview.
I'd be thrilled to answer any questions.
BONUS: https://codepreview.io has a button for hn users where you can join a room to discuss this project live (no-login required), I intend to leave this for a few hours.
Thanks!
EDIT: I set my title as "Launch HN" but it was automatically changed to "Show HN", I guess this is an hn restriction.
This is an interesting question, the codepreview integration can operate without a backend, in fact, some existing integrations work this way.
Still, a backend helps to:
1. Distribute the necessary settings/scripts to create a preview, this is now handled by a plain-old (password-protected) file server.
2. Allow users to manage their projects, for example, set variables/secrets, configure a custom domain, etc.
> how is it different from other companies
The main difference is that we did not go to the K8s way, which help us to easily integrate projects without asking our customers to adapt their project to us.
Besides that, there are no bots behind our contact pages, so far, we have a very close relationship with our customers.
> like Retool, Zeet, etc.
I wasn't aware about these tools, still, they seem to be tools for creating applications while codepreview allows generating previews for existing applications.
Is that a fair comparison?
1. Netlify/Vercel handle production deployments while codepreview does not.
2. Netlify/Vercel have many more features than codepreview, still, codepreview is more flexible in what it can, do you want to pre-create users for each preview? no problem, do you SQS queues? you can get those, etc.
3. Vercel/Netlify are mostly about frontend previews (tied to js) while codepreview handles fullstack previews, in our demo, we showcase a web app preview built with Scala/Scala.js/Postgres, other stacks are supported too (like Java-based ones).
4. Vercel/Netlify charge per user while codepreview charges a fixed fee for all your users.
Hope my questions help you in making an sharper elevator pitch to customers.
You have reminded about a comparison chart we are drafted but never published.
Uhh... that's really slow. What is CodePreview doing to make it take that long? You could spin up a VM and copy a binary over to it much faster than that.
I'd love to see more tooling in this space (most people don't need Docker!) but I didn't get a sense of what CodePreview is actually doing from the homepage.
Building everything from source can take a while for some projects, for example, Scala/Rust. In our case, most of the projects we have integrated depend on Scala.
Other than that, CodePreview also provisions dependencies (databases, etc), generates SSL certificates + some other steps.
I have personally done some experiments to reduce these times and getting these down to less than 3 minutes seems doable, I have drafted a blog post explaining this. For simpler projects, it's easy to get the execution time to 1 minute.
> You could spin up a VM and copy a binary over to it much faster than that.
Copying the binary is one of the fastest steps.
There are projects take take less time,
> I'd love to see more tooling in this space (most people don't need Docker!) but I didn't get a sense of what CodePreview is actually doing from the homepage.
Is there anything more specific you can share? This is the 3rd time we work on polishing the landing page to make our purpose clear, it seems we are not there yet.
In short, Codepreview reacts to commits on Pull Requests, executing a pipeline that builds and deploys a temporal app version (using a new sub-domain specific to each PR), this way, you can preview the how the app looks like and how it behaves without pulling the code yourself, it has turned out to be very helpful for demos.
Thanks for your feedback.
Gotcha, true. I think you're doing yourself a disservice by including compile times (mostly out of your control) in your answer to "How long does each preview environment take to deploy?"
> Is there anything more specific you can share?
I would like to hear some technical details about the environment that each temporal app version gets deployed to. Like, is it a normal VM I can remote into? Docker containers? Something fancy like Firecracker micro-VMs?
You might not want to make all of those details public, but I need a bit more of an understanding of how a product works to consider using it.
This is a very good point I haven't considered, I just updated the FAQ.
> I would like to hear some technical details about the environment that each temporal app version gets deployed to. Like, is it a normal VM I can remote into? Docker containers? Something fancy like Firecracker micro-VMs? > You might not want to make all of those details public, but I need a bit more of an understanding of how a product works to consider using it.
I believe the landing page isn't the right place to share these, I'm working on adding a blog where these details would be explained.
To summarize, every customer gets its own powerful VM where all previews will run, previously, ssh-ing into the VM is doable but it hasn't been required since we started exporting the application logs.
Each preview is being executed as a systemd service with nginx in front to handle TLS.
If you are interested to know any particular detail, feel free to ask.
Thanks.
For example, I have worked with teams who have lots of hardcoded details that prevent the app to work in multiple environments.
Is it staging?
It has 3 VPs and two 128gb 24 core CPU servers.