Now v1 / Heroku / Render Hosting

Now v1 / Heroku / Render Hosting



  • we would dogfood the service internally and remove as a dependency
  • k8s mvp via abram
  • fork saasify CLI
  • use OSS ZEIT/now builders
  • basic dashboard



Competitive Analysis

  • now v1 (shut down)
  • - like now but for static ipfs sites
  • begin





  • Deployments
    • Docker-only for MVP
    • Follow the now v1 workflow & config as closely 1:1 as possible
    • Shortly after MVP add utils for common runtimes
      • Node.js
      • Python
      • etc
  • DNS
    • Basic CNAME and alias support for MVP
    • NOTE: we have to carefully consider how this is implemented alongside Saasify proxying our backend API.
    • I think that Saasify should only proxy our backend API and services hosted on our platform should be served via a separate DNS ingress and load balancer that doesn't have anything to do with Saasify.
      • Abram Isola can you confirm this proposed design? Travis Fischer Yup. That's what I would think.
    • Purchasing domains
      • NOT MVP
    • Importing domains to our DNS
      • NOT MVP
  • GitHub integration
    • NOT MVP
  • Persistent storage
    • NOT MVP
    • Post-MVP ability to attach persistent shared disk(s) to a deployment like render allows
    • In either case, we recommend using an externally hosted DBaaS instead of hosting your DB with us
    • If using K8s: Storage can be a PITA. Consider solutions like Longhorn
  • CDN (sitting in front of our application load balancer)
    • Not important for MVP
    • We may get this by default via Saasify's backend proxy, depending on how we implement the application proxying
      • Same with rate limiting and standard caching
      • Using Cloudflare edge workers under the hood
      • Scratch that; I think we don't want Saasify to proxy hosted application traffic — we only want it to proxy our platform's backend CRUD for managing deployments
  • Web dashboard UI
    • NOT MVP
    • MVP webapp will use default Saasify auth and acct mgmt UI
    • Post-MVP webapp will include a basic UI that mirrors the CLI's CRUD functionality to list and manage your projects & deployments
    • Use as general UI inspiration



MVP Roadmap Proposal

  • TODO: use saasify for billing, identity, and api gateway?
    • would be great for saasify development
    • might slow us down in the early stages
  • fork saasify's backend crud api
  • encapsulate abram's k8s as a module or service used by the backend api
    • TODO: work with Abram Isola to define exactly what this interface looks like

Core Backend Resources

  • Project
    • id: string // namespace/name
    • name: string
    • user: Ref<User>
    • team: Ref<Team>
  • Deployment
    • id: string // namespace/name@hash
    • hash: string
    • user: Ref<User>
    • team: Ref<Team>
    • project: Ref<Project>
    • build: Map<string, string> // build-time env vars & secrets (post-mvp)
    • env: Map<string, string> // run-time env vars & secrets
    • adaptor: Enum // docker only for now
    • dockerImageUrl: string // URL to the docker image
    • url // auto-generated public URL for this deployment
    • // in the future, i'd want to store a merkle tree of the hashes for the different files that comprise the source of this deployment, so we can quickly diff deployments and cache shit
    • source: string // URL to a compressed blob of source data (post-mvp once we support building docker images from source)
    • builder: Enum // source to docker image builder (post-mvp)
    • config: Map<string, string | number> // things like auto-scaling preferences (post-mvp)
    • disks: Disk[] // config for persistent disks (post-mvp)
    • Abram Isola what, if any, additional properties would we want Deployment resources to have aside from their unique id in terms of relating them to their derived k8s resources?
      • I would assume that most state will be inferred from the corresponding k8s resources, but we may want to denormalize some basic state here like "did this deployment build correctly" and "is this deployment" reachable? anything that might appear in a UI listing all of your deployments and their high-level state. def tradeoffs here to consider
  • User
    • normal user metadata shit
  • Team
    • normal team metadata
    • creator: Ref<User>
    • members: Ref<User>[]
  • Secret
    • id: string
    • user: Ref<User>
    • team: Ref<Team>
    • key: string
    • // wherever we store the secret's value, key should be enough to retrieve it

Misc Questions

  • Abram Isola
  • Is a single k8s cluster appropriate to handle all users and all deployments for MVP? What about post-MVP?
    • Travis Fischer For MVP, yes. Post-MVP, probably but there could be a debate had here. Either way, I would stick to one cluster for the time being.
  • Post-MVP, how do k8s federation and multi-region deployments work? Are there any changes to these core resource models that would be useful to consider ahead of time?
    • Travis Fischer Huge topic. Lots of unanswered questions in the industry for this. Not useful to consider ahead of time. No changes necessary to core resources would be helpful up front.
  • How exactly should DNS work for deployments and production aliases?
    • Would love to see a rough sketch here for reference.
    • Travis Fischer This isn't really as hard as you may think. We don't really need to worry too much about it. I'm not sure what exactly you want in a sketch.
      • Publicly available app gets a subdomain (
      • User can CNAME/ANAME/ALIAS a domain to that subdomain. They then have to tell us about that domain. We next poll the DNS to check that it routes to (and/or the IP address to support ANAME/ALIAS).
      • When we find that it routes, then we can use it as a host, manage TLS, etc.
      • There are some implementation details that are glossed over here... But it isn't really that difficult to automate.
      • Note: We don't actually manage any DNS here for anybody except for our own * domain name which should/will be managed by an actual DNS zone manager anyway.
  • What are Abram's thoughts on using node.js for the backend api?
    • I would prefer to use a language that we can both easily contribute to, and 95% of this can be forked from saasify
    • Travis Fischer If it's a node backend you can count me as useless. I have also experienced major usability issues with the Node k8s library. The only k8s libraries that are really used in production in serious k8s implementations are the Go, Python, or Java libraries. I have only used the Go one in production, but the Python one has a long history of being used in production as well.
    • I could be convinced to use Python for the backend as well.
  • Do we care about differentiating ourselves from Render / Heroku at all?
    • I feel like v1 should be a heavy mix of now v1 and render
    • Maybe down the road we consider positioning
    • Travis Fischer Yeah, let's focus on the rock solid UX first - differentiation will happen when we learn who is using it and why IMO.



Naming Notes

  • ideal name for CLI is 3-5 letters
  • uniqueness & SEO would be great but not a hard constraint

Naming Keyword Brainstorm

one command

Possible Names

(focusing on names with reasonable & available domains)
  • zing
    • (owned by abram)
    • npm package squatted ⇒ we could get it
  • cloudy
    • npm package squatted ⇒ we could get it
    • possibly - meh
    • - meh
    • - meh
  • serverful
  • easycloud - meh
  • pliable
  • peasy - meh
  • (booo .now TLD isn't publicly available)
  • vmnow
  • vm-now
  • nowv1
  • now-v1