TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Launch HN: LayerCI (YC S20) - Staging servers that act like (and replace) CI

174 点作者 colinchartier超过 4 年前
Hi HN, Lyn &amp; Colin here. We’re co-founders of LayerCI (<a href="https:&#x2F;&#x2F;layerci.com" rel="nofollow">https:&#x2F;&#x2F;layerci.com</a>), which gives you a modern DevOps experience (CI&#x2F;CD &amp; staging environments) with as little work as writing a Dockerfile.<p>Most teams need CI&#x2F;CD (run the build and deploy every time a developer pushes) or staging (host a server with my app in it to share), but current approaches always have at least one of these problems:<p>- Simplistic (only run unit tests)<p>- Slow (wait 10 minutes to run the same repetitive setup steps like &quot;npm install&quot;)<p>- Complex (cache keys, base images, a slack channel to reserve staging servers, …)<p>We’ve spent over a year iterating with our customers to build a product that solves all of these problems.<p>Our configuration files (Layerfiles) look like Dockerfiles, so regular developers can write and maintain them. Here&#x27;s one that creates a staging server for create-react-app:<p>FROM vm&#x2F;ubuntu:18.04<p>RUN curl -sS <a href="https:&#x2F;&#x2F;dl.yarnpkg.com&#x2F;debian&#x2F;pubkey.gpg" rel="nofollow">https:&#x2F;&#x2F;dl.yarnpkg.com&#x2F;debian&#x2F;pubkey.gpg</a> | sudo apt-key add - &amp;&amp; curl -fSsL <a href="https:&#x2F;&#x2F;deb.nodesource.com&#x2F;setup_12.x" rel="nofollow">https:&#x2F;&#x2F;deb.nodesource.com&#x2F;setup_12.x</a> | bash &amp;&amp; apt-get install nodejs python3 make gcc build-essential<p>COPY . .<p>RUN npm install<p>RUN npm test<p>RUN BACKGROUND npm start<p>EXPOSE WEBSITE <a href="http:&#x2F;&#x2F;localhost:3000" rel="nofollow">http:&#x2F;&#x2F;localhost:3000</a><p>We charge a flat $42&#x2F;mo&#x2F;developer on our paid plan. Because it&#x27;s a flat fee and not usage based, we&#x27;re incentivized to make things as fast as possible: Our current margins come from a custom-built hibernating hypervisor that lets us avoid running &quot;npm install&quot; thousands of times per day.<p>We’ve upgraded the free tier to 5GB of memory for new installations this week. It’s perfect for personal projects or small MVPs where you’d like a powerful demo server that will build on every push and automatically hibernate when it’s not being used.<p>The easiest way to try out LayerCI is to follow our interactive tutorial: <a href="https:&#x2F;&#x2F;layerci.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;layerci.com&#x2F;</a> or look at the docs: <a href="https:&#x2F;&#x2F;layerci.com&#x2F;docs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;layerci.com&#x2F;docs&#x2F;</a><p>We would love to hear your thoughts about CI&#x2F;CD, staging, and what we’ve built!

20 条评论

benkoller超过 4 年前
Great approach. I&#x27;ve been running ops teams for a long time, and eventually all teams have ended up spending some time optimising our CI tooling to involve some degree of caching - so you definitely are on to something.<p>Before I clicked your pricing I&#x27;d really wished for an affordable pricing plan to run this on BYO resources, but only your enterprise plan seems to cover this. I always get an iffy feeling when I have to build my software on external resources I have 0 control over. Your downtime will prevent teams from shipping their code - but I guess that thought is part of your upsell to the enterprise plan.<p>Anyway, it&#x27;s one of these ideas I&#x27;d wish I had years ago, so congratz to you.
评论 #25981104 未加载
thruflo超过 4 年前
Congrats on the launch :)<p>The pricing incentives sound smart.<p>Do you see the ability to replicate more complex architecture as a differentiator? For example, one of your homepage quotes mentions &quot;running a Kubernetes stack inside of a Layerfile&quot;. Can you elaborate more on how Layerfiles enable this?
评论 #25980977 未加载
julienlafond超过 4 年前
Hi @colinchartier!<p>From what I see your product looks great for running a single app with a ready-to-use staging environment.<p>In practice, a stating environment is often not limited to one app, but at least 1 frontend inter-connected with at least 1 backend (and often, many frontends connected to many micro-services).<p>Does your product respond to this kind of architecture?
评论 #25983847 未加载
old-gregg超过 4 年前
I see developer tools on HN. I upvote!<p>Congrats on launching! I know this is a good idea because we actually invested time in building something similar internally.
评论 #25982132 未加载
mcintyre1994超过 4 年前
This sounds really exciting. I love your live demo, really slick introduction and tutorial - and answered some questions I had about E2E! I&#x27;ve got a couple of other questions though.<p>&gt; 12 full stack preview environments per commit with up to 16GB of memory and 6 CPUs<p>Quote from your pricing. If we had a monorepo with over 12 small test&#x2F;integration jobs, but not 12 full preview environments, is this usable? Are they one and the same, or can we have eg. a suite of unit tests that don&#x27;t count toward this full preview limit? Do some teams keep some unit tests off Layer and just use you for the more interesting pieces?<p>Second, do you have any documentation about which databases you support? Concretely can you restore a MongoDB snapshot super-fast?<p>Third, do you have any story around secrets if we want the staging server to hold some secret API keys? Currently we can do this with AWS (own account) CI machines in Gitlab deploying to ECS with AWS secrets - they stay end-to-end encrypted and nobody sees them. Is there any similar way we can get secrets onto a staging server without you having access to them? I suspect this would be a deal breaker for the staging use case for my team.<p>Similar to above, our database snapshots are stored in non-public S3 buckets, how would that work? Again currently it&#x27;s a case of giving the CI AWS role permission to access them, not sure what an equivalent would look like.<p>One more, is it possible to access the built docker images? We deploy Docker images to ECS, and currently they&#x27;re the exact same ones built and tested in CI which is a nice reassurance. Do your customers have an out-of-band process for building + deploying to production outside of Layer?<p>Aside, I think this may be a typo on your pricing page? &quot;We&#x27;ll never increase your the terms of your bill once you start your subscription.&quot;
评论 #25989030 未加载
评论 #25992185 未加载
mamcx超过 4 年前
This sound very tempting!<p>I run Rust CI for Windows&#x2F;Linux (on azure pipelines) and it need art least 1h to complete, with several tricks already done.<p>When something broke the iteration is very slow to fix it (you wait 1h, then find the problem, then publish, another hour, you forget something...)<p>So I have a local deployment so i can fix things faster, but is like negating the whole point.<p>If yours can help in deploy rust faster chime in <a href="https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.reddit.com&#x2F;r&#x2F;rust&#x2F;</a> because is a major pain point!<p>P.D: I assume this not include osx&#x2F;windows?
评论 #25981985 未加载
rumblecat超过 4 年前
I&#x27;m looking at your docs, and the RUN REPEATABLE command seems really powerful. But if the state is broken after a run, like if you have some pods stuck at Terminating, how would you recover things?<p>Another question I have is how would you handle state that sometimes needs to update and sometimes doesn&#x27;t? For example, it would be ideal to have a staging database that can keep having migrations and data added to it when new features are added, but we only want to checkpoint the changes to it from testing when the PR is actually merged.
评论 #25981196 未加载
1337shadow超过 4 年前
&gt; - Slow (wait 10 minutes to run the same repetitive setup steps like &quot;npm install&quot;)<p>That should happen any time you change dependencies if your Dockerfile is efficiently setup, not every time you change a line in runtime code ...<p>Maybe that:<p>COPY . .<p>RUN npm install<p>Is not what you should do to have an efficient docker build phase, did you try this instead ?<p>COPY package.json<p>RUN npm install<p>COPY . .<p>Multistage builds will help if you build in two languages in the same Dockerfile.<p>Anyway, still slow when you add&#x2F;remove a package because it redownloads everything, my best trick is to share ~&#x2F;.npm cache directory, but I manage this with buildah instead of docker build.
评论 #25981588 未加载
aloknnikhil超过 4 年前
Nice work! I played around with the demo and launched an SSH session for the last layer (hosting the website). And I was able to trigger a VM reboot from the shell. And now the website is not up anymore. Curious to know if there&#x27;s any monitoring or alerting that I can see when something like this is happening? And how do I go about debugging it&#x2F;restoring functionality?
评论 #25981156 未加载
gajus超过 4 年前
How is this different from the likes of <a href="https:&#x2F;&#x2F;vercel.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;vercel.com&#x2F;</a> ?<p>It doesn&#x27;t need to be – but understanding the difference &#x2F; similarities with other tools that have a similar sounding proposition helps with user acquisition &#x2F; defining your niche.
评论 #25984925 未加载
评论 #25984559 未加载
data_ders超过 4 年前
How does dependency caching configuration work? I get wanting to make things as fast as possible, but I struggle a bunch a Python dep caching in Circle CI... is there a way to ensure a 100% rebuild? Also interested to see how you plan to support open source
评论 #25982954 未加载
mrkurt超过 4 年前
This is super cool. I would like to know more about VM hibernation!
评论 #25981010 未加载
Lyn_layerci超过 4 年前
Colin&#x27;s cofounder here :) Excited to hear from you all
0xbadcafebee超过 4 年前
<i>&quot;LayerCI is an all-in-one devops platform, but we provide three main value propositions to our users:&quot;</i><p><pre><code> - Run e2e tests on every commit. - Collaborate easier with per-PR staging environments. - Set up CI&#x2F;CD to build and deploy to production </code></pre> Anyone can do this without your company. If that&#x27;s the value you bring, then I don&#x27;t need your company. What value do you bring that I can&#x27;t get somewhere else?<p>Also, red flag: mis-use of the term DevOps for marketing purposes.<p><i>&quot;There are a few ways of thinking about these files named ‘Layerfile’:&quot;</i><p><pre><code> - Auto-discovered Dockerfiles that build entire virtual machines instead of containers, just as quickly. - Define a tree of virtual machines. Each subsequent layer can inherit all the running processes in its parents. - Trigger specific actions like build, push, test, and deploy in parallel every time you push new code. </code></pre> It&#x27;s not explained well what benefit there is to using VMs rather than containers. Later on it briefly mentions possibly better caching than Docker containers. If it&#x27;s actually better than Docker, you are <i>severely</i> burying the lede. &quot;Better than Docker&quot; should be on the front page. It&#x27;s also not explaining whether I need to throw away all the time and money I might have already invested in containers, or what this is and isn&#x27;t compatible with.<p>A lot of this solution is really built around optimizing one specific problem, which is caching during re-running whole CI pipelines. This limits the viability of your business. As soon as your customers figure out a new way to solve this problem, they don&#x27;t need your custom platform anymore. I would consider LayerCI more of a specific feature of a much larger offering.<p>(In particular, the &#x27;correc&#x27;t way to solve this problem is to stand up an environment for your PR and structure your CI so you only re-run the parts that affect the particular change you want to make, rather than re-running the entire pipeline. It involves putting more thought into running your pipeline but often means the only tasks that get executed are copying a file and restarting your app)<p>P.S. You&#x27;re installing the yarn GPG key and then not doing anything with it. Your node setup script isn&#x27;t installing the yarn repo or yarn itself, so this is a throwaway command.
评论 #25981626 未加载
评论 #25990037 未加载
tekno45超过 4 年前
Can we get SSO for not a bajillion dollars?<p>Seems like this functionality is really inflated across the entire SaaS space.<p>Is SSO really that hard? that expensive?
评论 #25982966 未加载
danpalmer超过 4 年前
This looks great. I’m interested in your approach to databases and specifically the data in staging environments?<p>I’ve found setting up the data in databases for staging environments can take as much time as CI, and often works in quite a different way. Shared databases can work, but then may limit staging changes that include migrations.
评论 #25992201 未加载
malthejorgensen超过 4 年前
As an early user -- the speedups are very real! Feels great to just skip build step after build step, due to Docker-like layers.
评论 #25981316 未加载
pdeva1超过 4 年前
how do you know which steps to skip or rerun each run. in your react example, how do you know when to reinstall yarn to latest version and when to skip. <a href="https:&#x2F;&#x2F;layerci.com&#x2F;docs&#x2F;examples&#x2F;react" rel="nofollow">https:&#x2F;&#x2F;layerci.com&#x2F;docs&#x2F;examples&#x2F;react</a>
评论 #25992234 未加载
colinchartier超过 4 年前
If you&#x27;d like to chat with me (CEO @ LayerCI) personally, I&#x27;m at colin@layerci.com
technics256超过 4 年前
What&#x27;s the difference between this and something like hashicorp waypoint?