scalarium.com Syndication

Scalarium price reduction

2012-05-01T00:00:00Z

We are happy to announce the first ever Scalarium price drop.
We will lower our management fees by up to 48% effective today!
Check out the new hourly instance prices below.

The new prices

Type	Old price	New price
Standard Instances
Small Instance	0.03 €	0.02 €
Medium	0.06 €	0.04 €
Large	0.12 €	0.08 €
Extra Large	0.24 €	0.16 €
High-Memory Instances
Extra Large	0.18 €	0.11 €
Double Extra Large	0.42 €	0.22 €
Quadruple Extra Large	0.84 €	0.44 €
High-CPU Instances
Medium	0.06 €	0.04 €
Extra Large	0.24 €	0.16 €

The new pricing is effective immediatly as of May 1st 00:00 UTC for all instances, regardless if already running or not. The bill for April, which you will get in a couple of days, will have the old prices. The bill for May, which you will receive beginning of June, will have the new and lower prices.

You can view your current bill and the costs per cloud in your settings.

We would like to thank all our customers for their loyalty and feedback.
We <3 you!

Updates: South America region, Standard Medium instance, deployments out of Amazon S3, Scalarium API

2012-03-27T00:00:00Z

Our last update here was some time ago. We worked hard on awesome new features. Today we will announce only a few small things, but be assured that we have bigger features to announce soon ...

Support for new region and instance

We added support for the new South America (Sao Paulo) region as well as the new Standard Medium (m1.medium) instance. Be aware that the instance prices for regions differ (EC2 instance prices), the Scalarium costs are the same for all regions.

The new instance Standard Medium comes with:

3.75 GB memory,
1 core with 2 EC2 Compute Units,
410 GB instance storage,
and with an 32-bit or 64-bit platform.

So this is the ideal box to use for a smaller database instead of the high CPU medium instance which has in comparison a little more CPU power and two cores but just 1.7 GB memory. Right now we offer the Standard Medium instance in its 64-bit flavor. We will add the support for 32-bit version later.

S3 deployments

We added the possibility to deploy directly out of Amazon S3.

Why did we do this although we already offer git, svn, and http download deployments?

S3 is a highly available, reliable and secure place to store your deployment artifacts. Because of S3s higher availability compared to your own git/svn server or services like github.com/beanstalkapp.com this could be very interesting if you want to ensure that you can deploy any time. This of course comes with a little drawback. You will have to update the S3 object manually or via your CI- or build-process. This is rather easy if you already use a continuous integration server like Jenkins.

If you want to deploy via S3 you can choose this option while creating a new, or editing an existing application.

The repository URL is the link to your S3 object, the username an AWS access key, and the password the corresponding secret key. You won't need to enter your 'Master' Access Keys. Instead you can create an IAM user in the AWS Management Console. This IAM user needs reading access to the object that shall be deployed - that's all.

In the following screen shot you can see the click path for creating a new IAM user.

You will have to attach a user policy to the newly created user. This user policy can be the predefined AmazonS3ReadOnlyAccess rule, which reads as the following:

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:Get*",
        "s3:List*"
      ],
      "Resource": "*"
    }
  ]
}

In you deployment logs you will find instead of a svn or Git checkout the download from S3 and the extraction of the downloaded archive.

Here you can see another reason why deploying out of S3 is fun. It is really really fast!

Scalarium API

We also added the possibility to list, create, and delete Amazon Credentials in Scalarium. You can lookup how this works in our knowledge base article.

node.js version selection

2011-11-21T00:00:00Z

We deployed support for node.js apps some months ago. When you wanted to select a node.js version different from the default, you had to do so with, for example, custom JSON.

Until today.

You can now select the node.js version via the node.js settings, stored with your node.js app server role. Of course, you can still set the version by using custom JSON.

Improved instance selection when repeating deployments

2011-11-18T00:00:00Z

When you deploy an application with Scalarium, you can pick the instances to deploy to. Unless you explicitly deselect some instances, the deployment hits every running instance.

We changed that behavior slightly for repeated deployments.

Say you have a deployment in a cluster with two running instances. During that deployment you decided to skip one instance. When you repeat that deployment, the skipped instance is still skipped, all other running ones are selected for deployment.

For 24/7 instances that results in every instance that was selected before, but it also includes load and time based instances that were not running before but are running when you repeat the deployment.

Introducing the Scalarium client

2011-11-17T00:00:00Z

When working on an instance over SSH, there are lot of jobs that need to be done again, and again, and again. Because Scalarium focuses heavily on automation, we thought it would be a good idea to create a handy tool that helps us with these jobs - the Scalarium Client.

From now on, the client is part of the Scalarium agent, which runs on every instance. The client is symlinked in /usr/sbin, so you can use it from anywhere.

Here's what it looks like.

root@instance:/# scalarium-client
usage: scalarium-client command [command options]

Commands:
    help   - Shows list of commands or help for one command
    list   - List all chef JSON files and their activities (setup, configure, ...)
    log    - View the latest or a given chef log file
    run    - Do some real work, call help run for details
    status - Display useful information

The client makes things easy that were possible before, but tedious. It tells you what happened on your instance, as an overview or in detail. It tells you the status of the Scalarium agent.

The client also lets you do things that weren't possible before.

Imagine you want to run a single custom recipe from the command line, but with all benefits from the Scalarium UI.

The client does that for you.

Your recipe is run
Custom JSON defined in the Scalarium UI is automatically included.
The chef run is shown in the associated instance's logs in the Scalarium UI.

Give it a try, and have a look at our knowledge base for details and examples.