8 ms·

Show HN: Shuttle – Build and ship backends without writing infrastructure files

167 points by dohman 3y ago

lijok 3y ago
Now this is how you turn a language mainstream.
- farmeroy 3y ago
  I'm really excited to see more adoption of Rust in web development, Shuttle seems like at least a positive sign things are moving that way
- oldpersonintx 3y ago
  [dead]
jbotdev 3y ago
Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages. That said, the “infrastructure-from-code” idea is interesting. I’m not a big fan of coupling your code to your infra, but I’m intrigued by the idea of inferring infra dependencies from existing application code.
- dohman 3y ago
  You got that right. What Shuttle is trying to do, among other things, is to extract the difficulties of getting started, especially in a language like Rust, so that you can focus on writing good code and moving fast (when moving fast is a requirement).
- earthling8118 3y ago
  My productivity in rust is so much higher because of the help I get on correctness. It's not even remotely a competition.
- FranGro78 3y ago
  If you find the “infrastructure from code” idea intriguing, then maybe take a look at https://www.winglang.io https://www.winglang.io It’s a new startup by an ex-engineer on the AWS CDK team.
  - notnmeyer 3y ago
    this is wild
- satvikpendem 3y ago
  The type system makes development much faster than with a language that doesn't have a strong type system.
- dralley 3y ago
  > Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages. I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.
akerr 3y ago
Oh, “build backends fast”.
lucgagan 3y ago
From my experience with Rust, there is nothing fast about developing with it.
- ramon156 3y ago
  Its not aimed towards fullstack anyway. You CAN write webapps, and leptos is an amazing tool! But developing in leptos is a huge bottleneck. It takes to build than angular, and that says enough
  - the__alchemist 3y ago
    I love Rust for embedded and building PC applications, but don't use it in this domain due to the lack rich frameworks. Ie that have DB ORM (Like Django or SQLAlchemy vice Diesel), auth, email, security, admin, templating etc. On the plus side, Rust has serialization and timezones down with best-in-class solution via Serde and Chrono .
- sitkack 3y ago
  From my experience with Rust, there is nothing faster for delivering a solid system. Both of these comments contain zero worthwhile information.
- qweqwe14 3y ago
  Rust is not a prototyping language. If you need something done quick&dirty, pick e.g. Python. Personally I don't feel like writing something in Rust would take significantly more time than any other language, provided you know Rust pretty well already.
  - oldpersonintx 3y ago
    [dead]
  - steve_adams_86 3y ago
    I prototype with Python despite being fairly familiar with rust. Arguably less familiar with Python. I really abuse Python, like a kid cramming plato together and shoving toothpicks and googly eyes on it. If someone asked me to make something well with Python I’d need to take a breather and really think about it. I can do the same thing with rust, but making changes to that monstrosity would be relatively hard. With Python I can rip something out and replace it without a whole lot of fuss. After doing that for a few days or weeks, I might know what I should actually build. At this point, building with rust is pretty quick but it’s only because I’ve got a clear target and a somewhat sensible design to follow, if I squint at it. Then I can drop kick the Python part and pretend it never happened. But I’ve never worked with anyone who works at the same speed in Rust from the start. It doesn’t seem to happen. On the other hand, I’ve watched people struggle with it for days and weeks on end over things that seem trivial.
kjfarm 3y ago
My brain read this as “Build Back, Ends Fast.” I thought trends were changing so quickly I now miss them before I even know about them. Glad I still have a few years left of semi-keeping pace
- dohman 3y ago
  Haha, yeah, HackerNews corrects 'Backend' to 'Back End' automatically.
eandre 3y ago
If you like the concept but prefer Go over Rust for backends, check out Encore [1]. Disclosure: I'm one of the founders. [1] https://encore.dev https://encore.dev
irf1 3y ago
interviewed the CEO on the OSS founder podcast earlier this year :) full interview (38min): https://youtube.com/watch?v=GBT7yp17P4Y https://youtube.com/watch?v=GBT7yp17P4Y highlights (10min): https://youtube.com/watch?v=TVco_9E9no8 https://youtube.com/watch?v=TVco_9E9no8
jeffypoo 3y ago
Not sure if being so opinionated about Rust is a good idea, but very cool nonetheless. Looks well done, excited to tire kick it. Curious how you see this stacking up against things like Pulumi?
- openquery 3y ago
  Disclaimer: I'm one of the co-founders of Shuttle. Also, I haven't used Pulumi so I don't want to misrepresent it. However, as far as I understand, Pulumi is an infrastructure _as_ code solution, offering an SDK in various languages which wrap providers enabling you to define your desired infrastructure. In the context of a cloud provider like GCP, this means wrapping the existing GCP primitives and services (i.e. GKE) and enabling you to declare your desired infrastructure in your favourite programming language. Shuttle is an infrastructure _from_ code solution. The infrastructure that is provisioned for you is defined implicitly by your application's code. Static analysis is done at compile time to figure out what you need implicitly (i.e. if you're using a database connection pool, you probably need a database). Furthermore Shuttle offers its own primitives (i.e. secrets management) without a necessary correspondence to an underlying cloud provider (although there are some, like AWS RDS).
revskill 3y ago
The easy done right ! Rust + Postgres on a stateful server for CRUD apps.
TruthWillHurt 3y ago
Good luck competing with AWS! went great for my serverless platform startup (and everyone else..)
brainbag 3y ago
I've been surprised at how much I like Rust for backend work, but looking at the read me I have no idea what the case for this tool is. What do you use it for?
- dohman 3y ago
  It let's you deploy apps quickly and manage infrastructure without having to battle the AWS console and/or config files. A simple server (via most Rust frameworks) can be deployed by utilizing an annotation and then running `cargo shuttle deploy` whereas adding a resource, like a Postgres database for example, is also a matter of adding an additional annotation.
- yuppiepuppie 3y ago
  Glad Im not the only one. I checked out their examples repo, and Im still very confused as to what the library does. The shuttle runtime trait has me very confused as the API is built on Rocket.
- dohman 3y ago
  Out of curiosity, what was the first impression you've got and/or what were you expecting to see?
  - ctvo 3y ago
    That it's for toy projects. Using annotations to provision infrastructure hides complexity from you, but that complexity is what's required to actually manage and resolve infrastructure issues in production. In a prototype or toy project, sounds great.
    - openquery 3y ago
      This argument can be made at any level of abstraction I think. For example, you can make the same case for AWS Lambdas abstracting the infrastructure away from you, or VMs that run on-top of a hypervisor abstracting away the bare-metal servers. IMO it really boils down to the quality of the implementation of a product and also designing your product such that if users need to debug (which hopefully isn't often) you offer that visibility into the internals.
rubenfiszel 3y ago
We do a bit the same at windmill.dev except for python and typescript and we parse the parameters directly from the signature without needing to use macros/annotations. I wonder if the same could not have been done here where the macro would have been as a build processor.
- ashiban 3y ago
  That's what we do with Klotho [0], annotations are only used to close behavioral gaps that are not available in application code. (I'm one of the founders) [0] https://klo.dev https://klo.dev
sbt567 3y ago
It would be great if there are some kind of code snippet on the README that really demonstrate the "ship backends without writing infra" feature that I think is one of the unique feature of shuttle. I remember seeing one on the official website (https://shuttle.rs https://shuttle.rs) that left me impressed.
ctvo 3y ago
Infrastructure from code is the least exciting development in the evolution of ops I've seen. Helping manage complexity -- great. Pulumi, Terraform, the CDK, all of these infrastructure as code tools help manage complexity. Hiding complexity behind a DSL, via comments attached to methods intermingled with code or annotations -- not great. Some of these implementations are my business logic -> your DSL via annotations or comments -> <Some other IaC DSL> -> CloudFormation -> AWS. At some point the returns are diminished as you add more layers vs. the cost of operating what's generated and trying to debug issues.
- postalrat 3y ago
  The devops answer to complexity is always more complexity.
  - BerislavLopac 3y ago
    That's pretty much the fundamental theorem of software engineering. [0] https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
  - deleted 3y ago
    [deleted]
    - deleted 3y ago
      [deleted]
  - rewmie 3y ago
    > The devops answer to complexity is always more complexity. I don't think this is a valid take. The main responsibility of DevOps is automation. You cannot automate without writing code, which by definition means introducing complexity. You either introduce complexity by writing low-level scripts, or by adopting a tool/framework which allows you to write high-level code by hiding the low-level code in their entrails. I feel your comment implies that DevOps mindlessly adds complexity, when the truth of the matter is that it greatly simplifies everything at the expense of surfacing all the complexity that forced the world to treat all the cattle as fragile little pets.
willsmith72 3y ago
Maybe the title should specify "rust backends" or "rust applications"
gdcbe 3y ago
I use shuttle to deploy some side Rust projects for my web facing parts. I love it. They are also planning to allow you to host it yourself via a docker setup, in your basement or cloud. For now I’m just doing it via their service and gladly pay for it. If you’re well versed into DevOps related activities you might find it odd that there’s a need for it. But personally I’m a father of 3 kids, have been a developer and and hacker for last 12 years or so, and while I could do AWS, gcloud or a VPS myself, I honestly rather spend that time on my product then infra worries. So far I haven’t experienced any issues with them and they are very friendly folks, always ready to help. They’ll also be at EuroRust next week. If you’re like me someone who likes to develop stuff but not so much the deployment side of things, then honestly this is nice. There’s honestly no lock-in: 1. You’re service (project) can easily be converted into a regular project, as shuttle is in code only visible in a minimal way, so you can fairly easily refactor it out of your project the day you want to switch away 2. And like I said they’ll allow to self host soon enough. So maybe you can give it a try. Might be the accelerator you need to help you start a project / business idea. Even if just to get you started.
- bckr 3y ago
  Is there a reason to use this over, say, Render?
  - lucasyvas 3y ago
    I'm wondering this same thing - my current assessment is no and that a YAML config is superior to compile-time macros. If I used Shuttle, I'd probably be using cfg-if and type aliases anyway to stop it from infecting the majority of my code. The proposed benefit of having a compile-time validated config is not a tangible one in my opinion. I don't think the abstractions are that beneficial either. This is kind of a harsh assessment, but maybe it's just not for me.
  - gdcbe 3y ago
    No. It’s just another alternative. I’m not a web developer in my day job. So I’m not aware of all options out there. Render does look awesome. More mature and all. It’s not as easy as shuttle though. - shuttle comes with a cli that allows you to run your app in similar fashion as the cloud version - with shuttle you don’t need to configure the storage (eg db) and such yourself That said. The price you pay is tighter coupling to the system. On top of that Render looks a lot more mature. For now I’ll stick with shuttle for those projects. But I do thank you for telling me about render. Might switch to it, away from shuttle, if I my project’s needs ever outgrow shuttle’s capabilities
0xbadcafebee 3y ago
HN bingo card for the comments thus far: [x] mentions Rust [x] mentions Go [x] misunderstanding the word DevOps [x] compares product to Heroku [x] "I just want to write code and make/run a product and not know how that works" [x] something about scaling [x] the solution to any problem is to write more code
- c0balt 3y ago
  I think everytjing is one ppint except that this page doesnt mention Go(lang) anywhere.
  - quadcore 3y ago
    He got ya.
  - demi56 3y ago
    [dead]
- ForHackernews 3y ago
  Ctrl + f "Heroku" => yours is the only result?
- deleted 3y ago
  [deleted]
oldpersonintx 3y ago
[dead]
MichaelMug 3y ago
Is there anything like this for the Python/Django world?
turtlebits 3y ago
Without infrastructure files means polluting your code with vendor specific lines. I'm not sure how much better that is. I'm not so keen on a single language only SaaS either. How many companies only deploy code in a single language?
iio7 3y ago
Yes, let's have even more of people just writing code and not knowing anything about how anything works! Just what we need more of.
- toyg 3y ago
  Wrote any assembly recently?
- nurettin 3y ago
  In my younger days, a successful compilation step was reason for shipping it. Has that changed?
kevincox 3y ago
> Is Shuttle Secure? > We build and deploy every project in its own container. This gives you safe isolation from other users and all the other projects that are owned by your account. So that's a "no". Containers are not strong security boundaries. Probably good enough between projects owned by your own account, but definitely not for between other users.

167 points by dohman 3y ago

lijok 3y ago

Now this is how you turn a language mainstream.

farmeroy 3y ago
I'm really excited to see more adoption of Rust in web development, Shuttle seems like at least a positive sign things are moving that way
oldpersonintx 3y ago
[dead]

jbotdev 3y ago

Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages. That said, the “infrastructure-from-code” idea is interesting. I’m not a big fan of coupling your code to your infra, but I’m intrigued by the idea of inferring infra dependencies from existing application code.

dohman 3y ago
You got that right. What Shuttle is trying to do, among other things, is to extract the difficulties of getting started, especially in a language like Rust, so that you can focus on writing good code and moving fast (when moving fast is a requirement).
earthling8118 3y ago
My productivity in rust is so much higher because of the help I get on correctness. It's not even remotely a competition.
FranGro78 3y ago
If you find the “infrastructure from code” idea intriguing, then maybe take a look at https://www.winglang.io https://www.winglang.io It’s a new startup by an ex-engineer on the AWS CDK team.
- notnmeyer 3y ago
  this is wild
satvikpendem 3y ago
The type system makes development much faster than with a language that doesn't have a strong type system.
dralley 3y ago
> Seems ironic that you’d use rust to “build fast”. My impression is that Rust is more about building things safe/correct and efficient, with developer productivity being lower relative to other modern languages. I have to admit that I have limited experience working deeply with Rust, but I've found thus far that my relative productivity is inversely proportional to the size of the project. That is, for large projects, Rust is much more productive than other languages. For small ones, less productive.

akerr 3y ago

Oh, “build backends fast”.

lucgagan 3y ago

From my experience with Rust, there is nothing fast about developing with it.

ramon156 3y ago
Its not aimed towards fullstack anyway. You CAN write webapps, and leptos is an amazing tool! But developing in leptos is a huge bottleneck. It takes to build than angular, and that says enough
- the__alchemist 3y ago
  I love Rust for embedded and building PC applications, but don't use it in this domain due to the lack rich frameworks. Ie that have DB ORM (Like Django or SQLAlchemy vice Diesel), auth, email, security, admin, templating etc. On the plus side, Rust has serialization and timezones down with best-in-class solution via Serde and Chrono .
sitkack 3y ago
From my experience with Rust, there is nothing faster for delivering a solid system. Both of these comments contain zero worthwhile information.
qweqwe14 3y ago
Rust is not a prototyping language. If you need something done quick&dirty, pick e.g. Python. Personally I don't feel like writing something in Rust would take significantly more time than any other language, provided you know Rust pretty well already.
- oldpersonintx 3y ago
  [dead]
- steve_adams_86 3y ago
  I prototype with Python despite being fairly familiar with rust. Arguably less familiar with Python. I really abuse Python, like a kid cramming plato together and shoving toothpicks and googly eyes on it. If someone asked me to make something well with Python I’d need to take a breather and really think about it. I can do the same thing with rust, but making changes to that monstrosity would be relatively hard. With Python I can rip something out and replace it without a whole lot of fuss. After doing that for a few days or weeks, I might know what I should actually build. At this point, building with rust is pretty quick but it’s only because I’ve got a clear target and a somewhat sensible design to follow, if I squint at it. Then I can drop kick the Python part and pretend it never happened. But I’ve never worked with anyone who works at the same speed in Rust from the start. It doesn’t seem to happen. On the other hand, I’ve watched people struggle with it for days and weeks on end over things that seem trivial.

kjfarm 3y ago

My brain read this as “Build Back, Ends Fast.” I thought trends were changing so quickly I now miss them before I even know about them. Glad I still have a few years left of semi-keeping pace

dohman 3y ago
Haha, yeah, HackerNews corrects 'Backend' to 'Back End' automatically.

eandre 3y ago

If you like the concept but prefer Go over Rust for backends, check out Encore [1]. Disclosure: I'm one of the founders. [1] https://encore.dev https://encore.dev

irf1 3y ago

interviewed the CEO on the OSS founder podcast earlier this year :) full interview (38min): https://youtube.com/watch?v=GBT7yp17P4Y https://youtube.com/watch?v=GBT7yp17P4Y highlights (10min): https://youtube.com/watch?v=TVco_9E9no8 https://youtube.com/watch?v=TVco_9E9no8

jeffypoo 3y ago

Not sure if being so opinionated about Rust is a good idea, but very cool nonetheless. Looks well done, excited to tire kick it. Curious how you see this stacking up against things like Pulumi?

openquery 3y ago
Disclaimer: I'm one of the co-founders of Shuttle. Also, I haven't used Pulumi so I don't want to misrepresent it. However, as far as I understand, Pulumi is an infrastructure _as_ code solution, offering an SDK in various languages which wrap providers enabling you to define your desired infrastructure. In the context of a cloud provider like GCP, this means wrapping the existing GCP primitives and services (i.e. GKE) and enabling you to declare your desired infrastructure in your favourite programming language. Shuttle is an infrastructure _from_ code solution. The infrastructure that is provisioned for you is defined implicitly by your application's code. Static analysis is done at compile time to figure out what you need implicitly (i.e. if you're using a database connection pool, you probably need a database). Furthermore Shuttle offers its own primitives (i.e. secrets management) without a necessary correspondence to an underlying cloud provider (although there are some, like AWS RDS).

revskill 3y ago

The easy done right ! Rust + Postgres on a stateful server for CRUD apps.

TruthWillHurt 3y ago

Good luck competing with AWS! went great for my serverless platform startup (and everyone else..)

brainbag 3y ago

I've been surprised at how much I like Rust for backend work, but looking at the read me I have no idea what the case for this tool is. What do you use it for?

dohman 3y ago
It let's you deploy apps quickly and manage infrastructure without having to battle the AWS console and/or config files. A simple server (via most Rust frameworks) can be deployed by utilizing an annotation and then running `cargo shuttle deploy` whereas adding a resource, like a Postgres database for example, is also a matter of adding an additional annotation.
yuppiepuppie 3y ago
Glad Im not the only one. I checked out their examples repo, and Im still very confused as to what the library does. The shuttle runtime trait has me very confused as the API is built on Rocket.
dohman 3y ago
Out of curiosity, what was the first impression you've got and/or what were you expecting to see?
- ctvo 3y ago
  That it's for toy projects. Using annotations to provision infrastructure hides complexity from you, but that complexity is what's required to actually manage and resolve infrastructure issues in production. In a prototype or toy project, sounds great.
  - openquery 3y ago
    This argument can be made at any level of abstraction I think. For example, you can make the same case for AWS Lambdas abstracting the infrastructure away from you, or VMs that run on-top of a hypervisor abstracting away the bare-metal servers. IMO it really boils down to the quality of the implementation of a product and also designing your product such that if users need to debug (which hopefully isn't often) you offer that visibility into the internals.

rubenfiszel 3y ago

We do a bit the same at windmill.dev except for python and typescript and we parse the parameters directly from the signature without needing to use macros/annotations. I wonder if the same could not have been done here where the macro would have been as a build processor.

ashiban 3y ago
That's what we do with Klotho [0], annotations are only used to close behavioral gaps that are not available in application code. (I'm one of the founders) [0] https://klo.dev https://klo.dev

sbt567 3y ago

It would be great if there are some kind of code snippet on the README that really demonstrate the "ship backends without writing infra" feature that I think is one of the unique feature of shuttle. I remember seeing one on the official website (https://shuttle.rs https://shuttle.rs) that left me impressed.

ctvo 3y ago

Infrastructure from code is the least exciting development in the evolution of ops I've seen. Helping manage complexity -- great. Pulumi, Terraform, the CDK, all of these infrastructure as code tools help manage complexity. Hiding complexity behind a DSL, via comments attached to methods intermingled with code or annotations -- not great. Some of these implementations are my business logic -> your DSL via annotations or comments -> <Some other IaC DSL> -> CloudFormation -> AWS. At some point the returns are diminished as you add more layers vs. the cost of operating what's generated and trying to debug issues.

postalrat 3y ago
The devops answer to complexity is always more complexity.
- BerislavLopac 3y ago
  That's pretty much the fundamental theorem of software engineering. [0] https://en.wikipedia.org/wiki/Fundamental_theorem_of_software_engineering https://en.wikipedia.org/wiki/Fundamental_theorem_of_softwar...
- deleted 3y ago
  [deleted]
  - deleted 3y ago
    [deleted]
- rewmie 3y ago
  > The devops answer to complexity is always more complexity. I don't think this is a valid take. The main responsibility of DevOps is automation. You cannot automate without writing code, which by definition means introducing complexity. You either introduce complexity by writing low-level scripts, or by adopting a tool/framework which allows you to write high-level code by hiding the low-level code in their entrails. I feel your comment implies that DevOps mindlessly adds complexity, when the truth of the matter is that it greatly simplifies everything at the expense of surfacing all the complexity that forced the world to treat all the cattle as fragile little pets.

willsmith72 3y ago

Maybe the title should specify "rust backends" or "rust applications"

gdcbe 3y ago

I use shuttle to deploy some side Rust projects for my web facing parts. I love it. They are also planning to allow you to host it yourself via a docker setup, in your basement or cloud. For now I’m just doing it via their service and gladly pay for it. If you’re well versed into DevOps related activities you might find it odd that there’s a need for it. But personally I’m a father of 3 kids, have been a developer and and hacker for last 12 years or so, and while I could do AWS, gcloud or a VPS myself, I honestly rather spend that time on my product then infra worries. So far I haven’t experienced any issues with them and they are very friendly folks, always ready to help. They’ll also be at EuroRust next week. If you’re like me someone who likes to develop stuff but not so much the deployment side of things, then honestly this is nice. There’s honestly no lock-in: 1. You’re service (project) can easily be converted into a regular project, as shuttle is in code only visible in a minimal way, so you can fairly easily refactor it out of your project the day you want to switch away 2. And like I said they’ll allow to self host soon enough. So maybe you can give it a try. Might be the accelerator you need to help you start a project / business idea. Even if just to get you started.

bckr 3y ago
Is there a reason to use this over, say, Render?
- lucasyvas 3y ago
  I'm wondering this same thing - my current assessment is no and that a YAML config is superior to compile-time macros. If I used Shuttle, I'd probably be using cfg-if and type aliases anyway to stop it from infecting the majority of my code. The proposed benefit of having a compile-time validated config is not a tangible one in my opinion. I don't think the abstractions are that beneficial either. This is kind of a harsh assessment, but maybe it's just not for me.
- gdcbe 3y ago
  No. It’s just another alternative. I’m not a web developer in my day job. So I’m not aware of all options out there. Render does look awesome. More mature and all. It’s not as easy as shuttle though. - shuttle comes with a cli that allows you to run your app in similar fashion as the cloud version - with shuttle you don’t need to configure the storage (eg db) and such yourself That said. The price you pay is tighter coupling to the system. On top of that Render looks a lot more mature. For now I’ll stick with shuttle for those projects. But I do thank you for telling me about render. Might switch to it, away from shuttle, if I my project’s needs ever outgrow shuttle’s capabilities

0xbadcafebee 3y ago

HN bingo card for the comments thus far: [x] mentions Rust [x] mentions Go [x] misunderstanding the word DevOps [x] compares product to Heroku [x] "I just want to write code and make/run a product and not know how that works" [x] something about scaling [x] the solution to any problem is to write more code

c0balt 3y ago
I think everytjing is one ppint except that this page doesnt mention Go(lang) anywhere.
- quadcore 3y ago
  He got ya.
- demi56 3y ago
  [dead]
ForHackernews 3y ago
Ctrl + f "Heroku" => yours is the only result?
deleted 3y ago
[deleted]

oldpersonintx 3y ago

[dead]

MichaelMug 3y ago

Is there anything like this for the Python/Django world?

turtlebits 3y ago

Without infrastructure files means polluting your code with vendor specific lines. I'm not sure how much better that is. I'm not so keen on a single language only SaaS either. How many companies only deploy code in a single language?

iio7 3y ago

Yes, let's have even more of people just writing code and not knowing anything about how anything works! Just what we need more of.

toyg 3y ago
Wrote any assembly recently?
nurettin 3y ago
In my younger days, a successful compilation step was reason for shipping it. Has that changed?

kevincox 3y ago

> Is Shuttle Secure? > We build and deploy every project in its own container. This gives you safe isolation from other users and all the other projects that are owned by your account. So that's a "no". Containers are not strong security boundaries. Probably good enough between projects owned by your own account, but definitely not for between other users.