apex / up Goto Github PK

Deploy infinitely scalable serverless apps, apis, and sites in seconds to AWS.

License: MIT License

Makefile 0.30% Go 96.75% JavaScript 0.92% Shell 2.03%

deployment aws lambda serverless api static deploy-tool golang nodejs aws-lambda

up's Introduction

Up deploys infinitely scalable serverless apps, APIs, and static websites in seconds, so you can get back to working on what makes your product unique.

With Up there's no need to worry about managing or scaling machines, paying for idle servers, worrying about logging infrastructure or alerting. Just deploy your app with $ up and you're done!

Use the free OSS version, or subscribe to Up Pro for a small monthly fee for unlimited use within your company, there is no additional cost per team-member or application. Deploy dozens or even hundreds of applications for pennies thanks to AWS Lambda's cost effective nature.

About

Up focuses on deploying "vanilla" HTTP servers so there's nothing new to learn, just develop with your favorite existing frameworks such as Express, Koa, Django, Golang net/http or others.

Up currently supports Node.js, Golang, Python, Java, Crystal, Clojure and static sites out of the box. Up is platform-agnostic, supporting AWS Lambda and API Gateway as the first targets. You can think of Up as self-hosted Heroku style user experience for a fraction of the price, with the security, isolation, flexibility, and scalability of AWS.

Check out the documentation for more instructions and links, or try one of the examples, or chat with us in Slack.

OSS Features

Features of the free open-source edition.

Pro Features

Up Pro provides additional features for production-ready applications such as encrypted environment variables, error alerting, unlimited team members, unlimited applications, priority email support, and global deployments for $19.99/mo USD. Visit Subscribing to Up Pro to get started.

Quick Start

Install Up:

$ curl -sf https://up.apex.sh/install | sh

Create an app.js file:

require('http').createServer((req, res) => {
  res.end('Hello World\n')
}).listen(process.env.PORT)

Deploy the app:

$ up

Open it in the browser, or copy the url to your clipboard:

$ up url -o
$ up url -c

up's People

Contributors

Stargazers

Watchers

Forkers

puppycodes atufkas cwonrails bradparks vermuz jondot domhofmann mdshahrouq k0shk0sh ljnchn tookit timbuchwaldt joshuapinter wonderbeyond armish spencermountain tarex theharveyz nickpisacane simonw niilante n8io sundoze nanuclickity hhsnopek shortjared brikou advincze jessestuart opencollective kivlor jalateras jgrenat christianpv tauheedkhan ukd1 aarono cptpackage diorahman hoangpq kmiyashiro hhy5277 n7olkachev arunlodhi jamesramsay alvarlaigna mojodna franciscocpg happy-ferret silenceper lukeed etiv vdt envomer sbarcelona11 partinder suedadam gene-smith shanepelletier vpineda7 bobstrange chmac orteth01 ianrtracey skabbes bjwschaap puzanov guoyu07 ericnograles srt32 berryhill analect hellorachid selvakn dbravender motyar krosti njpatel filmaj wvides stefanwalther aryanugroho backupmanager l1kw1d royalicing linuxerwang lwhile spencercdixon matthewmueller dumbomir hesidoryn timqian fclaeys mydearxym imjerrybao ferhatelmas jaredfolkins datazource zerocry www3838438

up's Issues

Timelines?

So by when can we start using this? Seems really exciting. I don't like aws's console and UI its just too slow and I prefer automated stuff. Maybe this can replace my current server deployment and devops hell.

Status pages

Wouldn't be hard to have a little self-hosted CLI driven status page, especially if you don't need all the random stuff statuspage.io provides.

Would you use this if it:

Do you care about integrations?

Do you have a status page right now?

Optimize reverse proxy

Do some profiling and get the latency as low as possible, possible replace Go's reverse proxy with https://github.com/valyala/fasthttp, test unix domain sockets in Lambda as well, check heap and see what can be pooled. It's also making some assumptions about having concurrency of 1 at the moment, since that's the case with Lambda.

Make sure it's not decompressing gzip and recompressing either, not sure what the proxy does but I know net/http's client does this transparently, test with some larger responses.

Ruby support

Out of the box. This one seems like it's pretty tricky to get running in Lambda.

Dynamic SVG dashboard for repo readmes, displaying status, metrics, etc

Building https://github.com/tj/gh-polls today got me thinking, maybe it would be cool (kind of gimmicky) to have a single image you place in a project Readme, and it shows you an overview of metrics such as API latency, uptime, errors, CI status and others.

Basically an alternative to Geckoboard without paying for that, and your team automatically gets access to it since it's just in a readme or Wiki!

Sooner

Later

abstract out the datasource so it doesn't have to be CloudWatch
- Is there an open-source data fetching layer?
themes
date range switching

Twitter

kinda made the mistake of having accounts per product, but oh well, basically will act as a changelog, but then again my personal twitter is basically this as well, might not be worth it

Continous Integration via AWS CodeBuild

0.005 per minute, nice out of the box experience if you don't want to bother with Circle etc. 100 free minute per month.

Pricing table

For now list out the AWS cost so people don't have to go hunt down the cost of logging, API Gateway, Lambda, and so on. Later it would be great to have part of the CLI or app estimate this stuff for you.

Private endpoints

For internal APIs etc.

https://aws.amazon.com/blogs/compute/introducing-amazon-api-gateway-private-endpoints/?sc_channel=sm&sc_campaign=launch_&sc_publisher=TWITTER&sc_country=Global&sc_geo=GLOBAL&sc_outcome=awareness&trkCampaign=sm_Serverless_75404f00_VPC_endpoints_for_API_Gateway&trk=_TWITTER&sc_content=Serverless_75404f00_VPC_endpoints_for_API_Gateway&sc_category=Amazon_API_Gateway&linkId=53035291

Alternative platform / provider implementations

One goal is to deploy to other platforms, for now AWS will be the focus, however its guts are abstracted. Happy to hear what people would like to see!

What would you use?

Resource management (opinions please!)

Curious what peoples thoughts are regarding managing things like DNS records, alarms, etc.

One option is individual CLI commands, this would be a little easier to implement, but awkward since the team can't review/audit them, commit them to source control, and requires listing a bunch of resources to see the state of the world.

$ up dns ls
$ up dns add apex.sh blog.apex.sh A 52.0.16.118,52.1.119.170,....
$ up dns add apex.sh ping.apex.sh CNAME ping.netlify.com

The more "correct" approach these days would be more like Terraform infra-as-code style, where the config in your repo is the source of truth, though it may be less familiar/intuitive to some people.

For DNS looking something like the following (for apex.sh zone):

{
  "domain": "apex.sh",
  "dns": {
    "blog.apex.sh": {
      "type": "A",
      "value": [
        "52.0.16.118",
        "52.1.119.170"
      ]
    }
  },
  "ping.apex.sh": {
    "type": "CNAME",
    "value": "ping.netlify.com"
  }
}

Changes would be previewed via up plan which shows what will be updated/created/deleted etc and applied with up apply or similar. Note this is not a replacement for Terraform or CloudFormation, just need to provide enough for people to get apps bootstrapped.

Pros of CRUD style:

Familiarity due to matching Heroku and friends
?

Pros of Terraform style:

Single source of truth / overview of app just from reading app.json
Preview changes before applying them
Easily reviewable via GitHub
?

Any opinions?

What needs implementing for now:

PHP support

Add Otus example

Open source otus(1) and add an example

Up is same now.sh?

Up is same service that https://zeit.co/now?

Add --wait flag for stack deletion

By default it'll probably just remain async, but an option would be nice.

Load testing command

Basically latency.apex.sh as a command, but a distributed version of hey(1) so you can still use all the flags and test from N regions. This should be a cool way to highlight the benefits of #27.

Might make sense to just package this up as its own up application, instead of a command. Also then serves as an example of using up.

Continuous Integration examples for Circle, Travis, etc

So it's easy for people to get rolling with the existing CI services out there. What do you use?

If Up provided a "serverless" (via AWS CodeBuild) self-hosted CI out of the box, and it was cost effective, complete with CLI and dashboard, would you use it?

Improve zip performance

It's pretty decent now, 15k files / 60MB with filtering in ~350ms but needs profiling to see if we can improve that some more.

Pricing model for Pro

I haven't decided on this yet, likely tiered, I'd be happy if small companies with little funding don't have to pay much, startups and established companies can afford more. Perhaps by company size? Maybe just by feature-set, we'll see, happy to hear suggestions!

Recording the time required to create Up, that might help gauge how much time it would save someone as well haha, most teams should not be wasting time developing tooling, engineers are pricey!

Serverless Metrics solution

I have a ~60% complete "serverless" metrics solution, very low cost to get started, and scales indefinitely built on AWS tech. May or may not make this a hosted product or an optional part of Up (or neither).

Easily an order of magnitude more cost-effective than any other solution I've seen, even Prometheus etc running on EBS, and easier to operate since you don't have to manage any nodes, set up HA, replication etc.

So far my thing uses the same protocol as Influx, latency is still good however price, volume, simplicity of operation and query flexibility are given priority. The query engine has more in common with Elasticsearch, making it easy to return nested results etc, SQL is more appealing for simple stuff but pretty awkward when it comes to nesting.

Another possibility is a CloudWatch compatibility layer so it's a vastly more cost effective drop-in replacement.

Curious what you use already:

What's most important for your use-cases?

Default error pages

Maybe, it would be nice to at least check Accept and output some nice HTML instead of boring text.

AWS account bootstrapping

For people who don't have an account or are unfamiliar with AWS, make this as easy as possible.

Log retention config

Default is unlimited I believe

Gatspy example

https://www.gatsbyjs.org/

Tail logs by optional app name

Tailing is implemented already, however it would be nice if you didn't need to cd around to switch apps.

Graphql API

API idea from @gjohnson to provide pro users for easier centralized management in an org for less IAM mayhem. Tempted to add some IAM management stuff to Up as well to make that a bit easier as an admin.

Install via npm

Not a big deal since it'll be a single copy/paste command anyway, but the install script could be published to npm to make that a little smoother for Node people.

https://github.com/Automattic/cloudup-cli is using the "up" package currently, but it's basically a dead project.

Add Hugo example

with build / clean hooks

Support for databases

Will there be an option for database support?

Documentation

Using Gitbooks for now probably!

Gitignore parity support

Currently ** is not supported. The pkg I'm using isn't very well documented, probably best to just fork or write a new one.

CLI polish

Make sure up stack and friends all have nice output and user-friendly errors, remapping of names (no one wants to see AWS::Lambda::Permission blah blah), etc.

Upgrade command to update up(1)

Just like apex(1). It would be cool to check remotely maybe once per day too, and show the changelog

move apex's logic to a distinct package
add to up and test

HTTP cache middleware

support conditional-GETs out of the box

Rust support

Looks like cross compiling is not super easy right now, might have to do docker builds. Any suggestions from Rust users?

Limits middleware

limit request header/body

Faster gitignore style pattern matching

Current pkg uses regexps, not a big deal for most projects but node_modules typically has an easy 10k files. On my machine the current regexp based stuff is ~22k ops/s, not super quick, likely easy to notice on large projects.

Comparisons

Some kind of table showing some of the pros/cons of Up vs other solutions so people know what to expect, for ex Lambda doesn't let you deploy using custom Dockerfiles, not really a problem in most real-world apps that I've written though.

Desktop app

App and web app will utilize the same code base. The desktop app will be targeted more towards people like myself, while the web app will be optionally self-hosted in your own network for private access by team members.

The app will features pretty much everything the CLI will, ranging from stats, alarms, continuous integration, and so on.

What would you prefer?