Show HN: Celest – Flutter Cloud Platform


124 points | by dillonnys 13 days ago


  • solatic 12 days ago
    I played around with Flutter a couple years ago for a project that required a mobile app, and walked away really impressed with Flutter and Dart. It's a much, much nicer language for building UI in compared to React Native and even the native languages. But the backend story with Dart was very much neglected. I got the feeling that Flutter's main developers at Google were the driving force behind Dart development, and the lack of backend adoption for Dart at Google was causing it to wither on the vine for backend purposes.

    Is the ecosystem support improving here? People end up needing libraries for all kinds of backend stuff, not just auth and SQL like you have on your roadmap. What about sending emails, hooking into payment providers / billing, queues/pubsub, observability...? Doesn't this need to exist first, to make building backends in Dart feasible, before building a framework that makes it easier?

    • dillonnys 12 days ago
      The ecosystem support is improving, and still needs help. I think we can drive both in parallel so that the framework feeds use cases to the ecosystem which then lead to more complex backends. It's hard to put one before the other, but can be a really powerful flywheel.

      Although it's not listed on my landing, it is absolutely a goal of Celest to be a funnel for these use cases and partner with the community as we go to fill the gaps.

  • e12e 13 days ago
    Looks interesting. What are your plans for the backend - will self-hosting be an option?

    Right now this looks fine for a hobby project, but massive lock-in/risk for production (what if you shut down, get bought up etc?).

    • dillonnys 13 days ago
      Great points.

      My immediate plan for reducing lock-in is to provide the option to deploy into a cloud account you manage. This has the upside of making your deployed infrastructure independent of Celest and letting you use your cloud credits.

      Self-hosting is another option I'm considering, but I don't have a good sense yet of what that could look like. Any thoughts? Is spitting out a binary/Dockerfile sufficient to alleviate risk?

      If I get shut down, I'll be open-sourcing all my code. And regardless, I plan to open source more and more of the platform over time.

      • marcglasberg 13 days ago
        Committing to open-source the code (and provide detailed instructions on how to run the code) in case the company shuts down is the most important. It could be part of the service contract. I've read all parts of the Celest code which are public, and I can attest it's very well-written and easy to understand.
        • dillonnys 13 days ago
          > It could be part of the service contract.

          Agreed. I'll look into how we can add that.

  • circafuturum 13 days ago
    I just listened to a podcast episode of the Flying High with Flutter podcast [1] where Celest founder, Dillon, was on as a guest. He came across as capable, hungry to get Celest out into the world, and focussed on solving problems around running dart in the cloud. All the best, Dillon, I'm looking forward to see where Celest goes!


  • mark_l_watson 13 days ago
    That looks cool, reminds me of long ago when I happily used Heroic, even though Celest is very different.

    Question: I know a few Clojure enthusiasts who really enjoy Clojure+Dart backend. Is Celest compatible for this workflow?

    • dillonnys 13 days ago
      Interesting! I don't know much about using Closure and Dart together. Any projects you could point me to? Sounds like a cool use case.
      • cgrand-net 12 days ago
        Hi, ClojureDart co-author here. Join us on #clojuredart of the Clojurians slack, we will help. Can code in `celest/functions` import from lib? We cou
  • firecall 13 days ago
    Question for OP:

    Obviously you are committed to Flutter and Dart.

    Where do you see it going, broadly?

    I’ve used Flutter a small amount and enjoyed it.

    But it’s a hard sell to commit fully to it.

    The alternatives of native tooling on iOS, Android and the web are not contentious choices.

    Whereas suggesting to a team or decision maker that Flutter is the right choice seems like it could be an uphill battle!

    As a solo dev making choices for clients that want a cross platform solution I can pitch Flutter as a somewhat rational choice against the cost of seperate builds for iOS and Android. Maybe, depending….

    Then there’s the Google factor… what if they get bored and kill Flutter!?

    • dillonnys 13 days ago
      These are reasonable concerns.

      Having seen the development of Flutter and its ecosystem over the past 7 years, I've come to really believe in the framework and its mission. There have been lots of companies which have found success building with Flutter [1] and it very often speaks to their bottom lines [2].

      I'm hopeful for its continued success, but more importantly, I believe that having more companies building enterprise solutions makes the technology more attractive and practical to adopt. The founder of Flutter has started Shorebird [3] and the FlutterFlow team recently closed a $25M Series A [4]. These are great investments to have into Flutter.

      Another cool stat: Dart was the fastest growing programming language among all languages last year at 33%! [5]

      All that to say, I believe the business value of Flutter is becoming clear and I think having more companies building on top will reduce adoption risk and create a very rich ecosystem for further progress.






      • nox101 12 days ago
        When I go to flutter examples and go to the first one

        I find everything is rendered in a canvas. This means it's not accessibility friendly. It means none of my extensions work. It means no text can be selected (for example clicking the 3rd icon from the top left labeled "Typography". It also means none of the Browser/OS level features are available. I can't select a word and pick "look up" or "define" or "speak". It's shows ugly monochrome non native emoji. It takes second to show non-English characters while it downloads non-English fonts

        How is this a win for the user?

    • marcglasberg 12 days ago
      Flutter tooling is superior to that of native iOS and Android development. It's not just about the cost savings from avoiding separate builds: Developing a Flutter app is generally easier than developing a separate app for either Android or iOS. And the developer experience is way better too.

      Google is not killing Flutter. Despite Google's rep, Flutter is a highly successful project that Google uses for many of its own products, including Google Pay, Google Classroom, and Google Ads. It's also used by other major companies:

  • marcglasberg 13 days ago
    Hey folks, I've created an open source app example using Celest, complete with tests and all. If think it demonstrates Celest use quite well. Here it is:

  • mixmastamyk 13 days ago
    Neat! Looks like you are using Flutter for the web front-end, is that right?

    I remember folks complaining about Flutter in the browser. Did that get fixed to an acceptable degree? And does that obviate the complexity of typical SPA framework on the frontend? With similar power?

    • dillonnys 13 days ago
      Right now, we're using Docusaurus, which has been working well:

      Though, Flutter Web has come a long ways recently, especially with the WASM work that's underway [1][2]. Flutter is very well positioned, I think, for web applications requiring a lot of interactivity and complex layouts--the DX is phenomenal. For static sites, it's very hard to beat a pure HTML/CSS/JS stack in terms of speed and optimization potential.

      That being said, I think there's a good chance we'll see more work on Dart web frameworks going forward. Projects like Zap[3] and Jaspr[4] and doing great work in this area already. And it's safe to say we may see a Celest Web framework one day!





      • mixmastamyk 13 days ago
        Thanks, believe you answered my question, though I may not have been clear enough before.

        I was asking about the demo app as shown in the video on the marketing site. The kinds of apps we'd be expected to build with this. Was not asking about the marketing site itself, though it seemed nice enough.

        • dillonnys 13 days ago
          Ah, gotcha! The choice to use Flutter Web in the demo was just for presentational effect. Celest is built to work with all of the Flutter platforms equally.
          • mixmastamyk 13 days ago
            Thanks. Is flutter required, or can we use Dart to return html, json, etc?
            • dillonnys 13 days ago
              Flutter is currently required for the parent app, but I'll be lifting that requirement very soon. Stay tuned!
  • hemmert 13 days ago
    Just what I needed for my next moonlight project :) Happy to try this out and give you feedback!
    • dillonnys 13 days ago
      Nice! Glad to hear it :-)
  • devon_c 12 days ago
    Great work Dillon!

    As you know the current setup with langpal's API is literally just next API routes from the marketing site. Bit of a strange and hacky coupling haha.

    Can't wait to see and use this!

  • evanlance 13 days ago
    Excelent news! Excuseme but where can i manage my free celest-cloud? i could run celest deploy with success but now i dont know how to use it and keep with the testings :D
    • dillonnys 13 days ago
      Glad to hear you ran a successful deploy!

      Currently we just have the CLI to manage your account, although I'm working on a web-based dashboard for better accessibility.

      The result of a deployment is just a URL, which is automatically placed in your generated client (see `celest/lib/client.dart`). To switch to this new environment, pass the production arg to your `celest.init` call like this:

          void main() {
            celest.init(environment: CelestEnvironment.production);
      Let me know if you face any issues! We have a Discord ( server, and you're more than welcome to open a GitHub issue if you experience problems:
      • marcglasberg 13 days ago
        Just to clarify what Dillon said:

        When you do `celest deploy` it sends your current code to the cloud. After that if your code contains: `celest.init(environment: CelestEnvironment.production);` it will use that code you just sent to the cloud. If your code contains `celest.init(environment: CelestEnvironment.local);` it will use the code you have in your local machine.

        But in practice you develop locally, so you don't need to deploy all the time.

        Also, you can call `celest.init` as many times as you like, while the app is running, to change from local to cloud and vice-versa, on the fly!

  • ruben_burdin 13 days ago
    We love Celest! This is the future of flutter.
  • mradek 13 days ago
    I really like flutter and dart. All the best with this Dillon!
  • flax 13 days ago
    The free plan says it includes "5,000 function invocations / project"

    I presume that's per month, not just 5000 free then pay up?

    How does this compare to hosted AppWrite, which also lets you write backend cloud functions in Dart?

    • dillonnys 13 days ago
      Per project, per month, yes. Felt like a mouthful to write, but I'll make that more clear.

      Celest's biggest strength with cloud functions is its integration with the Dart language. The CLI generates a strongly-typed API client for you which matches the declaration of your function, and handles all serialization out-of-the-box.

      So, if you write a top-level Dart function like this

          // In `celest/functions/my_api.dart`
          Future<String> sayHello(String name) async => 'Hello, name!';
      and save the file, you'll get a Flutter client which you can call as

          celest.functions.myApi.sayHello(name: 'Celest'); // Hello, Celest
      You can pass just about any Dart class between the frontend and backend, and it will just work. We're going for an RPC-style interface which means your types/parameters can never get out of sync.
      • gresrun 13 days ago
        How do you handle versioning? Are there any guidelines/rules one must abide by?

        It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?

        Do you support protobuf/cap'n'proto?

        • dillonnys 13 days ago
          > How do you handle versioning? Are there any guidelines/rules one must abide by?

          Versioning is not fully fleshed out yet, but we have an open issue for it here:

          It's a problem I want to tackle correctly, so that you'd need to put as little thought into it as possible. It should "just work". Vercel's skew protection [1] stands out as a recent example of doing this well.

          > It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?

          JSON was chosen as the primary serialization format for the reasons mentioned here [2]. Primarily, familiarity to Flutter developers, availability of JSON-compatible types in the wild, and integration with non-Dart clients.

          The JSON structure is outlined here (working on a full spec):

          built_value types can be used in Celest currently by giving the class `fromJson`/`toJson` methods. I haven't implemented auto-serialization for them, yet, but it should be straightforward. I've used built_value heavily in the past and agree there's no better alternative for some use cases.

          > Do you support protobuf/cap'n'proto?

          In the future, I plan to support more serialization formats, including protobuf and binary protocols. I will check out cap'n'proto, it was not yet on my radar.



  • adityathakurxd 13 days ago
    Just got the email with access! Congratulations to the you and team on the launch. Looking forward to trying it out.
  • Alifatisk 13 days ago
    I appreciate the free plan, any goals on adding celest to homebrew and chocolately?
    • dillonnys 13 days ago
      Yes, I definitely want to at some point. In the short term, I've implemented a `celest upgrade` method in the CLI, so it's just a one-time manual install.
    • dgellow 13 days ago
      Winget would make more sense than chocolatey
      • Alifatisk 13 days ago
        Right, it doesn’t matter in my case
  • DerCommodore 13 days ago
    What is the difference to Serverpod? can you elaborate here so I get a better view?
    • dillonnys 13 days ago
      Yes, absolutely. The main differences are

      1. Celest is fully managed and does not require any knowledge of the cloud. With Serverpod, you must have a cloud account and manage your own infrastructure.

      2. In Celest, all of your backend and infrastructure logic is defined solely in Dart. This differs from Serverpod which incorporates technologies like Docker, Terraform, and YAML to define your backend.

      There are similarities too. Celest will auto-generate a client library for you like Serverpod and provides a local development environment. Uniquely, though, Celest supports hot reload for your backend ;-)

    • marcglasberg 13 days ago
      I'd say the developer experience is completely different. With Celest you can almost pretend you are writing the frontend and backend code as one single codebase. And then you change a flag and the part of your code that needs to be in the cloud is moved to the cloud, seamless. I think you have to try it out to really grok how much easier it is.
  • moomoo11 13 days ago
    How long have you been working on it? Looks cool
    • dillonnys 13 days ago
      Thanks! I started working on it in November, but most of the effort has been over the past three months.