{"id":17047438,"url":"https://github.com/djmgit/deathstar","last_synced_at":"2025-06-12T14:37:13.019Z","repository":{"id":55406912,"uuid":"301055019","full_name":"djmgit/DeathStar","owner":"djmgit","description":"A tool for loadtesting web based services  in a easy, automated, cloud native and quick way without spending time on infrastructure setup for load generation.","archived":false,"fork":false,"pushed_at":"2021-01-10T06:08:24.000Z","size":8845,"stargazers_count":4,"open_issues_count":0,"forks_count":0,"subscribers_count":4,"default_branch":"master","last_synced_at":"2025-02-21T17:47:31.627Z","etag":null,"topics":["automation","chaos","devops","loadtesting","reliability","resiliency"],"latest_commit_sha":null,"homepage":"","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/djmgit.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2020-10-04T06:21:44.000Z","updated_at":"2025-01-12T05:09:45.000Z","dependencies_parsed_at":"2022-08-14T23:40:33.984Z","dependency_job_id":null,"html_url":"https://github.com/djmgit/DeathStar","commit_stats":null,"previous_names":[],"tags_count":1,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/djmgit%2FDeathStar","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/djmgit%2FDeathStar/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/djmgit%2FDeathStar/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/djmgit%2FDeathStar/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/djmgit","download_url":"https://codeload.github.com/djmgit/DeathStar/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":243489758,"owners_count":20299001,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["automation","chaos","devops","loadtesting","reliability","resiliency"],"created_at":"2024-10-14T09:49:29.811Z","updated_at":"2025-03-13T22:20:32.335Z","avatar_url":"https://github.com/djmgit.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"# DeathStar\n\nDeathStar is a tool to loadtest web based services and rest APIs in a easy, automated, cloud native and quick way without spending much time on infrastructure setup for load generation. DeathStar expects a configuration file with the details of the attack targets and it takes care of the infrastructure, spawns an ephemeral infrastreucture to carry out the loadtest on the target, generates the result and then tears down the infrastructure. Hence, the developer or the operations engineer does not have to think about the infrastructure for carrying out the attack/test. All that is exepcted from the user is to provide the config file.\n\n## What is the need for such a tool\n\nWhen working on or with web based services or APIs, performance testing of the service is extremely important. It gives us an idea some of the following unknowns\n\n- How much traffic (qps) can your application serve at peak hour. What is the qps at which your application breaks.\n- How does incoming load affects the resources consumed by your application. Is it memory intensive or processor intensive.\n- What is the right resource consumption level at which you should consider autoscaling? Do you need autoscaling at all?\n- What is the latency with which your application responds and how does it vary with load?\n- How does your application react to sudden bursts of traffic\n\nAbove are some of the unknowns which a developer or an operations engineer should try to find out about the web service they are working on. Also not to\nmention, with the advent of chaos engineering, we might want to artificially inject sudden large load into our web service to find out how our application\nbehaves in different situations like this.\n\nThere are several opensource tools present which allow us to loadtest applications by running them from command line or from UI. However the issue is, to carry\nout such attacks or loadtests, we require the necessary infrastructure from where we can run a given loadtest tool. Lets say we have spawned a server in \ncloud to run a loadtest tool on our application, now once we are done with our testing, we would not want our loadtest servers to be lying around idle, that \nwould be a waste of resource. So some one has to take the pain of spawning the server, orchestrating the tests and finally clean up the resources.\nAlso running such loadtest tools on shared servers which are already running some application can be risky as loadtest tools take up some resources and\nthat can affect the already running application.\n\nThe manual steps mentioned above come up not only as a time consuming problem but also pose issues when we are trying to carry out our loadtests in a automated way\nfrom CI pipelines. Someone would have to provision the neccessary resurce before running the pipeline and then clean it up afterwards or write additional scripts to\nautomate the same.\n\nComing back to DeathStar, it is not only a tool which can carry out loadtest and provide necessary data but it also takes care of infrastructure provisioning can\ncleanup by itself. All you have to do is provide config details so that it can orchestrate a successful test.\n\n## What exactly does DeathStar do and how does it do\n\n``` \nBefore I countinue further, I would like to mention that although deathstar is usable, it is still under development and features are \nbeing added. Currently it only supports AWS lambda as a compute backend. \n```\nDeathStar takes a configuration file, provisions a lambda function along with the handler, orchestrates the loadtest on the configured targets, displays the\nrecorded metrics and finally cleans up the lambda function, thereby allowing you to carry out your loadtest in a fully automated and serverless manner.\n\nIn the config file you can mention multiple targets and for each target you can provide the attack configurations like what should be the rate of the attack, that\nis, what should be the traffic qps, what is the endpoint that DeathStar will be hitting with the mentioned qps, what should be the HTTP method (right now it only\nsupports GET, but will support other methods along with body and url parameters in future) and for how long will the test be continued. It rquires some other\ndetails as well like the lambda memory size to be allocated, timeout, aws region etc, more on in subsequent sections.\nDeathStar will parse the config, accordingly create a lambda fucntion, invoke the lambda function for carrying out the attack and finally will destroy the lambda\nfunction. \nThis would be a nice time to mention that DeathStar uses \u003ca href=\"https://github.com/tsenart/vegeta\"\u003e Vegeta \u003c/a\u003e under the hood to create the load. Vegeta\nis a command line tool which allows you to generate load and hit a given web service endpoint. It also provides a library interface which is really awesome\nand is being used by DeathStar.\n\nDeathStar is written in golang and uses YAML configurations. In the next sections I will be talking more about how to setup DeathStar, configure it and carry out\nyour loadtest.\n\nDeathStar has been tested on **Linux** environment. However it can also be trigerred from **macOS** in case if someone wants to kickstart a test from his or her \nlocal mac system. The procedure for running it on macOS is however different from that on Linux. I will be discussing about this as well in later sections for this\ndocumentation.\n\n### QuickStart\n\nIn this section we will see how to configure DeathStar and get started with it.\n\n**Prerequisite**\n\nYou must have an active AWS account and the AWS CLI credentials set up in the environment from where you want to trigger DeathStar. This basically means the AWS\ncreds - ```aws_access_key_id``` and ```aws_secret_access_key``` should be setup either in ```.aws/credentials``` or as envronment variables. Right now DeathStar\ndoes not provide the option to pass these credentials via config file. It might do in future.\nAlso, you will be requireing a AWS role for your lambda function. Nothing special is required, its just the usual IAM role that the lambda function will assume so\nthe it has access to AWS resources. You can find more about it \u003ca href=\"https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-awscli.html\"\u003e here \u003c/a\u003e.\nIn short you can give the following trust policy\n\n```\n{\n  \"Version\": \"\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"Service\": \"lambda.amazonaws.com\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\n```\nand for permission you can use - ```arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole``` so that the lambda function can upload logs to CloudWatch.\nIn subsequent releases, the role creation will be automated so that DeathStar can create the role for itself and then destroy the role once test is done. However as\nof now its manual.\n\n**Setting up DeathStar**\n\nDeathStar can be setup on your system/pipeline in either of the two ways. Either you can download pre-built binaries from github or you can build it yourself.\n``` Please note : below instructions are for linux based systems and not for macOS. We have a separate section for running DeathStar on macOS ```\n\n**Using the pre-built sources**\n\nYou can setup DeathStar from prebuilt binary using the following steps:\n\n- Download the pre-built package suitabe for your system from the releases page.\n- Decompress the package : ```unzip \u003cpackage\u003e```\n- Optionally you can copy it to your path like ```/usr/local/bin```\n- Check out the binary ```./deathstar -help```\n\n**Building from source**\n\nYou can build DeathStar from source using the following steps. However before doing so make sure you have Golang 1.13.11 or above present in your system.\nFor building DeathStar uses GNU make.\n\n- Download or clone this repository\n- Open terminal and change directory to the project's directory\n- Run ```make build```\n- Your binary should be built and present in ```./dist``` directory present in project root.\n- Check the built binary using ```./dist/deathstar -help```.\n- To install DeathStar to your path, run ```make install```.\n- This will install deathstar under /usr/bin and you can invoke ```deathstar``` from anywhere.\n\nNow that DeathStar is setup we are ready for performing our first loadtest.\n\nAs mentioned already, DeathStar expects a single yaml configuration file in which the user will have to provide details about the targets to be attacked.\nThe user will basically have to provide a list of targets and some options related to them. Apart from target details user must provide some infrastructure\nrelated config options. Lets see a sample config file for orchestrating an attack.\n\n```\nattacks:\n  - attackName: attack-1\n    attackDesc: Test attack\n    vegetaAttackParams:\n      httpMethod: GET\n      url: \"https://url-1.xyz\"\n      rate: 2\n      duration: 2\n  - attackName: attack-2\n    attackDesc: Test attack2\n    vegetaAttackParams:\n      httpMethod: GET\n      url: \"https://url-2.abc\"\n      rate: 2\n      duration: 2\n  - attackName: attack-2\n    attackDesc: Test attack2\n    vegetaAttackParams:\n      httpMethod: GET\n      url: \"https://url-3.def\"\n      rate: 2\n      duration: 2\n\nlambdaConfig:\n  lambdaRole: \"lambda_role_arn\"\n  lambdaMemorySize: 128\n  lambdaTimeOut: 3\n  lambdaRegion: us-east-1\n```\n\nIn the above config, we are specifying three targets also known as attacks. In each attack definition we provide details like attack name, description,\nattack url, rate (qps) and everything else required by vegeta to carry out the attack on the given target endpoint. I will be mentioning in details about the\nindividual attack options in details in the configuration reference section.\nOnce we are done with our target descriptions required to orchestrate our attack, next we need to provide some details about the lambda configuration. These are\nrequired by DeathStar to spawn the on demand lambda function in the desired manner. We provide configs like the role arn - this is the role which we create in\nour prerequisite section, we provide the lambda memory size, depending on the attack scale we might want to change this. We can also specify the lambda timeout and\nthe region where where the function will be spawned.\n\nOnce we are satisfied with our configuration, we can trigger DeathStar to actually orchestrate the attack.\nIn order to run DeathStar, use the following command:\n\n```\n./deathstar -deploy -conf config.yml\n```\n\nThe above command will tell DeathStar to deploy the lambda function using the provided config, invoke the deployed lambda function with the attack details. The\nlambda function will then invoke its handler which will inturn invoke vegeta to attack the given targets on after the order. Right now DeathStar only allows\nsequential attack on the targets, in future it will provide attacking targets in parallel as well. Once the lambda execution completes, DeathStar will parse\nback the result and display it to the user in json format and finally destroy the lambda function.\n\nExample output:\n\n```\n\nNote: all duration like fields are in nanoseconds\n\n[\n\t{\n\t\t\"AttackResponseMetrics\": {\n\t\t\t\"latencies\": {\n\t\t\t\t\"total\": 318595407,\n\t\t\t\t\"mean\": 79648851,\n\t\t\t\t\"50th\": 39478544,\n\t\t\t\t\"90th\": 201993451,\n\t\t\t\t\"95th\": 201993451,\n\t\t\t\t\"99th\": 201993451,\n\t\t\t\t\"max\": 201993451,\n\t\t\t\t\"min\": 37644867\n\t\t\t},\n\t\t\t\"bytes_in\": {\n\t\t\t\t\"total\": 51430,\n\t\t\t\t\"mean\": 12857.5\n\t\t\t},\n\t\t\t\"bytes_out\": {\n\t\t\t\t\"total\": 0,\n\t\t\t\t\"mean\": 0\n\t\t\t},\n\t\t\t\"earliest\": \"2021-01-03T06:48:46.940882478Z\",\n\t\t\t\"latest\": \"2021-01-03T06:48:48.440780199Z\",\n\t\t\t\"end\": \"2021-01-03T06:48:48.479866919Z\",\n\t\t\t\"duration\": 1499897721,\n\t\t\t\"wait\": 39086720,\n\t\t\t\"requests\": 4,\n\t\t\t\"rate\": 2.6668485083990605,\n\t\t\t\"throughput\": 2.599116594967577,\n\t\t\t\"success\": 1,\n\t\t\t\"status_codes\": {\n\t\t\t\t\"200\": 4\n\t\t\t},\n\t\t\t\"errors\": []\n\t\t},\n\t\t\"attackDetails\": {\n\t\t\t\"attackName\": \"attack-1\",\n\t\t\t\"attackDesc\": \"Test attack\",\n\t\t\t\"vegetaAttackParams\": {\n\t\t\t\t\"httpMethod\": \"GET\",\n\t\t\t\t\"url\": \"https://url-1.xyz\",\n\t\t\t\t\"rate\": 2,\n\t\t\t\t\"duration\": 2\n\t\t\t}\n\t\t}\n\t},\n\t{\n\t\t\"AttackResponseMetrics\": {\n\t\t\t\"latencies\": {\n\t\t\t\t\"total\": 153277127,\n\t\t\t\t\"mean\": 38319281,\n\t\t\t\t\"50th\": 17974179,\n\t\t\t\t\"90th\": 112314614,\n\t\t\t\t\"95th\": 112314614,\n\t\t\t\t\"99th\": 112314614,\n\t\t\t\t\"max\": 112314614,\n\t\t\t\t\"min\": 5014155\n\t\t\t},\n\t\t\t\"bytes_in\": {\n\t\t\t\t\"total\": 506808,\n\t\t\t\t\"mean\": 126702\n\t\t\t},\n\t\t\t\"bytes_out\": {\n\t\t\t\t\"total\": 0,\n\t\t\t\t\"mean\": 0\n\t\t\t},\n\t\t\t\"earliest\": \"2021-01-03T06:48:49.205092672Z\",\n\t\t\t\"latest\": \"2021-01-03T06:48:50.705106735Z\",\n\t\t\t\"end\": \"2021-01-03T06:48:50.722270758Z\",\n\t\t\t\"duration\": 1500014063,\n\t\t\t\"wait\": 17164023,\n\t\t\t\"requests\": 4,\n\t\t\t\"rate\": 2.666641666012167,\n\t\t\t\"throughput\": 2.636473619616992,\n\t\t\t\"success\": 1,\n\t\t\t\"status_codes\": {\n\t\t\t\t\"200\": 4\n\t\t\t},\n\t\t\t\"errors\": []\n\t\t},\n\t\t\"attackDetails\": {\n\t\t\t\"attackName\": \"attack-2\",\n\t\t\t\"attackDesc\": \"Test attack2\",\n\t\t\t\"vegetaAttackParams\": {\n\t\t\t\t\"httpMethod\": \"GET\",\n\t\t\t\t\"url\": \"https://url-2.abc\",\n\t\t\t\t\"rate\": 2,\n\t\t\t\t\"duration\": 2\n\t\t\t}\n\t\t}\n\t},\n\t{\n\t\t\"AttackResponseMetrics\": {\n\t\t\t\"latencies\": {\n\t\t\t\t\"total\": 852066357,\n\t\t\t\t\"mean\": 213016589,\n\t\t\t\t\"50th\": 221749682,\n\t\t\t\t\"90th\": 292663955,\n\t\t\t\t\"95th\": 292663955,\n\t\t\t\t\"99th\": 292663955,\n\t\t\t\t\"max\": 292663955,\n\t\t\t\t\"min\": 115903038\n\t\t\t},\n\t\t\t\"bytes_in\": {\n\t\t\t\t\"total\": 97152,\n\t\t\t\t\"mean\": 24288\n\t\t\t},\n\t\t\t\"bytes_out\": {\n\t\t\t\t\"total\": 0,\n\t\t\t\t\"mean\": 0\n\t\t\t},\n\t\t\t\"earliest\": \"2021-01-03T06:48:51.445086615Z\",\n\t\t\t\"latest\": \"2021-01-03T06:48:52.945171147Z\",\n\t\t\t\"end\": \"2021-01-03T06:48:53.061074185Z\",\n\t\t\t\"duration\": 1500084532,\n\t\t\t\"wait\": 115903038,\n\t\t\t\"requests\": 4,\n\t\t\t\"rate\": 2.6665163960240075,\n\t\t\t\"throughput\": 2.475266564086257,\n\t\t\t\"success\": 1,\n\t\t\t\"status_codes\": {\n\t\t\t\t\"200\": 4\n\t\t\t},\n\t\t\t\"errors\": []\n\t\t},\n\t\t\"attackDetails\": {\n\t\t\t\"attackName\": \"attack-2\",\n\t\t\t\"attackDesc\": \"Test attack2\",\n\t\t\t\"vegetaAttackParams\": {\n\t\t\t\t\"httpMethod\": \"GET\",\n\t\t\t\t\"url\": \"https://url-3.def\",\n\t\t\t\t\"rate\": 2,\n\t\t\t\t\"duration\": 2\n\t\t\t}\n\t\t}\n\t}\n]\n```\n\nThe output shows various metrics measured by vegeta like mean latency, success ratio, status codes etc. Thus, we carried out a succesful loadtest without spending\nmuch time on the infrastructure side much. However as it was mentioned before, DeathStar does have some limitations and pitfalls, which I will be discussing about\nin the future scope and limitations section.\nAlso you might be wondering where is the lambda function code and handler and why are we providing a CLI option like ```-deploy```. I will be explaining the same\nin the subsequent sections.\n\n## Configuration options : Orchestrating a loadtest\n\nLets use our previous sample config yaml file to go over the different config options\n\n```\nattacks:\n  - attackName: attack-1\n    attackDesc: Test attack\n    vegetaAttackParams:\n      httpMethod: GET\n      url: \"https://url-1.xyz\"\n      rate: 2\n      duration: 2\n\nlambdaConfig:\n  lambdaRole: \"lambda_role_arn\"\n  lambdaMemorySize: 128\n  lambdaTimeOut: 3\n  lambdaRegion: us-east-1\n\n```\n\n**attacks**\n\nthe first section or yaml object key is ```attacks```. As the name suggests, this takes a list of attack configurations. You can also refer to this as target\ndefinitions. This list basically contains various targets to attack and details regarding how to attack, mostly required by vegeta.\n\n- **attackName**: This is just an identifier for a givenm attack. It is suggested to use some meaningful identifier so that you can easily identify your attack target.\n\n- **attackDesc**: A short description about the attack.\n\n- **vegetaAttackParams**: These are parameters/options which describes your attack as well as are required by vegeta to carry out the attack.\n\n- **url**: the web endpont that needs to be loadtested/attacked. Vegeta will bombard this endpoint with requests. This is the target.\n\n- **httpMethod**: The http method to be used by vegeta while hitting the target. Right now, DeathStar only allows ```GET``` but more types will be allowed soon.\n\n- **rate**: Number of requests to be made per second. This is basically the qps. This expects an integer.\n\n- **duration**: Number of seconds for which the attack will be continued. This should not be more than the lambda function timeout.\n\n\n**lambdaConfig**\n\nThe lambdaConfig yaml object keys takes parameters to configure the lambda function that will be created and invoked by DeathStar.\n\n- **lambdaRole**: This is the ARN of the AWS role to be used by the lambda function. This role must be created before using DeathStar.\n\n- **lambdaMemorySize**: The size of the lambda function. This takes integer and the unit is in Mega Byte. Default value considered by lambda is 128MB. We might\n  want to tweak this value depending on the scale of our attack. The vCPUs allocated by AWS to a lambda function is proportional to the memory it is allocated.\n  So if you want to generate higher load on your target then you will be requiring higher resources - memory and CPU. So you migth want to increase the memory\n  limit of the lambda function.\n  \n- **lambdaTimeOut**: This specifies the timeout for the lambda fucntion. It expects an integer and the unit is second. This specifies for how much time the function\n  will run. After the specified time period is over, the instance of the invoked function will be killed by AWS lambda. The value has a hard limit of 900, which is\n  15 minute. Unfortunately this is a limitation. However if you want to attack a target for than 15 minute, you can create two attack definitions with the same\n  target or invoke DeathStar again.\n  \n- **lambdaRegion**: This is simply the AWS region where you want DeathStar to spawn the function.\n\n## How does DeathStar work internally : Prcess flow\n\nLets start with taking another look at the DeathStar execution command:\n\n```./deathstar -deploy -conf config.yml```\n\nwhen we invoke this comand, the first thing that DeathStar does is, it tries to open the config file and read the configuration. First it picks up the\nconfig options provided for lambda and then it uses AWS Golang SDK to create a lambda function in the given region. Now as we know in order to create\na lambda function we need a zip file (if not S3) containing the function code. In our case, we do not have a separate\nfunction handler project for DeathStar, but ```DeathStar itself is the function handler``` . If we do not provide the ```-deploy``` CLI option, DeathStar's\nmain method will invoke :\n```\nlambda.Start(HandleLambdaEvent)\n```\nwhich is basically the AWS Go SDK's way of invoking the lambda function handler to handle request. This handler function will then invoke vegeta library\nto actually hit the target. So, DeathStar does both the jobs of orchestrating the attack by creating and invoking the lambda function as well as it\nitself handles the function invocation as the the lambda function and carries out the actuall attack. The ```-deploy``` option simply tells DeathStar that\nit is not running as a lambda function on AWS, but it is being run from some other system to orchestrate the attack. So to summarise, just before, DeathStar\ncreates the lambda function on AWS, it creates a zip package of itself (the binary being run) and provides the created zip file's path to the AWS SDK's create lambda function input.\nAs soon as the function is successfully created, it deletes the zip package.\n\nNow that we know how DeathStar creates and works as the lambda function lets continue with the flow. Next, DeathStar will find out the attack configutations\nprovided in the config yaml file under the ```attacks``` section and start invoking the lambda function for each of the targets provided. Right now the attacks\nare done sequentially one after the other but it will provide a way to do in parallel in future. After it was finished attacking all the targets it will display\nthe result and then clean up the lambda function.\n\n## Running DeathStar from macOS\n\nAll the above steps are for linux based systems. However you can run DeathStar from macOS as well, but the steps will be different to some extend. The main issue\nfor running DeathStar from macOS is the fact that DeathStar deploys itself as a function handler on AWS lambda as well. So its basically the same binary that runs\non your system (local, jenkins, instance, wherever) as well as on the lambda. However, this is not possible on macOS. Because macOS wont be able to linux ELF\nbinary (unless you are using a VM or a container in which case the scenario changes completely and will be same as running on linux). So, when running on macOS\nwe have to provide the zip package which will contain the elf binary of DeathStar and run the other binary on macOS which is built for macOS. And additionaly\nwe will have to tell DeathStar that do not create a zip of yourself but use the zip package provided by us while creating the lambda function.\n\nThe above, might sound complicated, but it is not actually so. Lets see who we can do this easily :\n\n**Using prebuilt packages**\n\n- Setup DeathStar in the same way as shown above using prebuilt packages, however use the prebuild package from ```macOS``` from the realese page.\n- Download the zip package for linux from here\n- Now you can run DeathStar using the following\n\n```\n./deathstar -conf [conf.yml] -deploy -local -zip-file-path [zip-file-path-to-the-linux-zip-package]\n\n```\n\n**By building from source**\n\n- Clone or download this repository and open it in your terminal.\n- First we need to make the zip package\n- Since we are building a Golang project binary on macOS, we need to tell Golang the target system is linux.\n- Run ```GOOS=linux make build```\n- This will build deathstar binary in the dist folder, you wont be able to run this binary as this is a linux elf.\n- Next for creating the package run ```make lambda_package```.\n- The above will create a zip file containing the linux elf in the root named ```deathstar.zip```\n- Next we have to build DeathStar for macOS. This can be done using ```make build``` command as we had done earlier. This will replace the linux binary\n  in dist folder with the binary meant to run on macOS.\n- Now you are all set. You can now run DeathStar using the following\n\n```\n./dist/deathstar -conf [conf.yml] -deploy -local -zip-file-path deathstar.zip\n\n```\n\nThe ```-local``` CLI option tells DeathStar that we want to use local zip file, hence DeathStar will not try to create a zip of its own. The ```-zip-file-path```\nsimply takes the path to the zip package which we want to use.\n\n## Features to be added\n\nAs already mentioned, DeathStar is in development. DeathStar should support the following features:\n\n- The AWS role creation for the lambda function is manual right now. This can be automated with the provision of providing custom role by user if required.\n- Conducting attacks in parallel. This will result in calling the created lambda function in parallel. For this we might also have to introduce an option\n  for configuring the lambda function concurrency.\n- VPC support: This is required for testing services which are private to a VPC and not behind public IP. DeathStar should be able to spawn the lambda function\n  in the desired subnet where the target service is running.\n- Right now the only supported backend is serverless lambda functions. However lambda function might not always be suitable for generating huge traffic. Parallel\n  running function (as mentioned in second point) may be usefull, still we may require alternate backends. DeathStar should support alternate backends like:\n  \n  -- EC2 instances: DeathStar should be able to spawn EC2 instances of desired type. We might be requiring higher number of vCPUs when generating huge\n     SSL traffic.\n     \n  -- Provision for integrating with Kubernetes compute: DeathStar can spawn pods dynamically, run the attack and then destroy the pods. This way we can utilise a\n     kubernetes cluster if already present.\n     \n     \n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdjmgit%2Fdeathstar","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fdjmgit%2Fdeathstar","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fdjmgit%2Fdeathstar/lists"}